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Capsule  Description 


This  curriculum  module  presents  a  framework  for 
understanding  software  product  and  process  specifi¬ 
cations.  An  unusual  approach  has  been  chosen  in 
order  to  address  all  aspects  related  to  “specification” 
without  confusing  the  many  existing  uses  of  the 
term.  In  this  module,  the  term  specification  refers  tc 
any  plan  (or  standard)  according  to  which  products 
of  some  type  are  constructed  or  processes  of  some 
type  are  performed,  not  to  the  products  or  processes 
themselves.  In  this  sense,  a  specification  is  itself  a 
product  that  describes  how  products  of  some  type 
should  look  or  ho».  processes  of  some  type  should 
be  performed.  The  framework  includes: 

•  A  reference  software  life-cycle  model 
and  terminology 

•  A  characterization  scheme  for  software 
product  and  process  specifications 

•  Guidelines  for  using  the  characterization 
scheme  to  identify  clearly  certain  life- 
cycle  phases 

•  Guidelines  for  using  the  characterization 
scheme  to  select  and  evaluate  specifica¬ 
tion  techniques 


Philosophy 


Most  SEI  curriculum  modules  provide  a  structure  for 
organizing  a  well-defined  subject  area  (sometimes 
related  to  a  life-cycle  phase)  and  a  guide  for  under¬ 
standing  the  related  literature.  They  are  addressed  to 
an  educator  audience,  but  contain  material  intended 
for  presentation  to  students.  This  module  has  all 
these  characteristics,  but  is  atypical  in  the  following 
ways: 

•  It  is  an  overview  module  covering  a 


broad  subject  area  about  which  there  is 
little  consensus. 

*  It  is  intended  to  provide  background  for 
understanding  other  curriculum  modules 
and  is  therefore  addressed  more  to  tea¬ 
chers  than  to  students. 

•  It  contains  a  good  deal  of  original  mate¬ 
rial,  embodying  an  unusual  approach  to 
its  subject  matter. 

The  term  “specification”  is  overloaded.  It  is  used 
both  informally  and  in  the  literature  in  a  great 
variety  of  senses,  and  it  is  difficult  to  achieve  a 
coherent  understanding  of  the  term  that  accounts 
adequately  for  this  diversity.  The  resulting  con¬ 
fusion  may  either  be  viewed  as  a  simple  terminology 
problem  (i.e.:  Which  life-cycle  products  or  processes 
should  be  referred  to  as  “specifications”?)  or  as  a 
more  fundamental  philosophical  problem  regarding 
the  role  of  “specification”  in  the  context  of  software 
development  (i.e.:  Can  the  notion  of  “specification” 
be  restricted  to  certain  life-cycle  product  and  process 
types?  Should  only  life-cycle  products  and  proc¬ 
esses,  only  their  plans,  or  both  objects  and  plans 
properly  be  called  “specifications”?). 

The  Terminology  Problem.  According  to 
[IEEE83],  the  term  “software  specification”  refers  ei¬ 
ther  to  a  document  or  product  that  describes  various 
characteristics  of  a  software  system  or  to  the  process 
of  developing  such  a  document  or  product  This 
general  definition  applies  to  a  large  variety  of  prod¬ 
uct  and  process  types1. 


1In  ihe  study  of  software  engineering,  individual  products  or 
processes  are  of  little  interest.  The  term  “type”  is  used  here  to 
denote  the  class  of  similar  products  or  processes  of  which  a 
particular  one  is  an  instantiation.  Thus,  for  example,  all  Ada 
programs  may  be  viewed  as  products  of  the  same  type  (i.e.,  Ada 
code  products);  all  coding  processes  based  on  stepwise  refine¬ 
ment  that  result  in  Ada  programs  may  be  viewed  as  processes  of 
the  same  type  (i.e.,  stepwise-refinement-oriented  Ada  coding 
processes). 
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Many  software  development  organizations  have 
adapted  this  definition  to  their  own  technological 
and  organizational  characteristics  and  needs.  The 
resulting  terminologies  are  context-dependent  and 
inconsistent  regarding  the  use  of  the  term 
“specification.”  Examples  of  inconsistencies  be¬ 
tween  existing  life-cycle  terminologies  include  the 
following  (see  Figure  1,  p.  20,  middle  column): 

•  The  same  term  is  used  for  product  and 
process  types  ( e.g .,  “requirements  defini¬ 
tion,”  “system  specification”). 

•  The  same  term  is  used  for  different  types 
of  products  (e.g.,  “requirements  specifi¬ 
cation,”  “functional  specification”). 

•  Different  terms  are  used  for  the  same 
type  of  product  (e.g.,  “requirements  spe¬ 
cification,”  “functional  specification”)  or 
the  same  type  of  process  (e.g.,  “require¬ 
ments  analysis,”  “system  specification”). 

Sometimes  the  same  product  may  be  referred  to  as 
“specification”  or  “implementation,”  depending  on 
whether  an  executable  specification  language  or  a 
high-level  implementation  language  is  being  used. 
Further,  the  same  software  characteristic  may  be  ad¬ 
dressed  in  one  or  more  products,  depending  on  the 
underlying  life-cycle  and  project  organization 
model.  And  processes  may  or  may  not  be  modeled 
explicitly,  depending  upon  the  perceived  importance 
by  the  organization  of  “process.” 

The  Philosophical  Problem.  Software  develop¬ 
ment  projects  should  be  explicitly  planned,  executed, 
and  evaluated.  The  project  model  depicted  in  Figure 
2,  p.  21,  reflects  these  principles  [Basili88],  It  is 
definitely  justifiable,  based  on  the  IEEE  definition 
[IEEE83] — it  is  probably  not  an  intended  interpreta¬ 
tion — to  view  both  a  number  of  life-cycle  products 
and  processes,  as  well  as  their  plans  resulting  from 
the  planning  activity,  as  “specifications.” 

The  purpose  of  planning  is  the  production  of  “plans” 
— whether  explicit  or  not — of  what  life-cycle  prod¬ 
ucts  should  look  like  and  how  life-cycle  processes 
should  be  performed.  Examples  of  such  plans  are,  in 
the  case  of  products,  the  ANSI/IEEE  830  standard 
on  “software  requirements  specification”  [IEEE84] 
and,  in  the  case  of  processes,  the  DoD  2 167 A  stan¬ 
dard  on  “software  development”  [DoD88a]  and  the 
DoD  2168  standard  on  the  “software  quality  as¬ 
surance  process”  [DoD88b],  The  purpose  of  execu¬ 
tion  is  to  perform  processes  and  construct  products 
according  to  their  plans.  The  purpose  of  evaluation 
is  to  assess  whether  the  plans  were  satisfactory  and 
whether  the  life-cycle  products  and  processes  were 
constructed  and  performed  in  accordance  with  their 
plans. 
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A  project  model  like  the  one  depicted  in  Figure  2 
enables  us  to  address  the  sound  selection  and  evalu¬ 
ation  of  software  specification  techniques,  i.e., 
models,  languages,  methods,  and  tools  used  to  create 
life-cycle  products  or  perform  life-cycle  processes 
according  to  their  specifications.  In  practice,  many 
major  software  development  failures  can  be  traced  to 
the  use  of  inappropriate  (as  well  as  inappropriate  use 
of)  techniques  for  describing  software  products  and 
processes. 

The  Approach  Taken  Here.  This  module  addresses 
the  above  problems  by  using  a  reference  life-cycle 
terminology  that  avoids  the  term  “specification”  for 
any  life-cycle  product  or  process  type.  Instead,  this 
module  refers  only  to  “plans”  of  product  and  process 
types  as  “specifications.”  Doing  so  eschews  existing 
life-cycle  terminologies  in  favor  of  one  that  facili¬ 
tates  consistency  in  the  present  exposition  and  al¬ 
lows  the  reader  to  reinterpret  this  module  in  terms  of 
some  other  nomenclature  he  or  she  prefers,  if  neces¬ 
sary.  In  this  module,  then,  a  software  specification 
is  a  product  resulting  from  the  planning  process  that 
prescribes  how  a  product  of  some  type  should  look 
or  how  a  process  of  some  type  should  be  performed. 
This  approach  may  seem  unusual,  but  the  author  is 
convinced  of  its  benefits. 

Module  Content.  This  curriculum  module  intro¬ 
duces  the  reference  life-cycle  model  and  terminol¬ 
ogy  discussed  above,  builds  a  scheme  for  charac¬ 
terizing  product  and  process  specifications,  uses  this 
scheme  to  describe  the  process  and  product  types  re¬ 
lated  to  certain  life-cycle  phases  of  the  reference 
life-cycle  model,  and  shows  how  such  characteriza¬ 
tions  may  be  used  to  select  and  evaluate  specifica¬ 
tion  techniques. 

Introduction  of  the  reference  life-cycle  model  and 
terminology  depicted  in  Figure  1  (left  and  right 
columns,  respectively)  represents  an  attempt  to  over¬ 
come  the  confusion  of  terminology  in  the  field. 
None  of  the  product  or  process  type  names  of  the 
reference  terminology  uses  the  term  “specification.” 
However,  cross  references  to  some  of  the  existing 
life-cycle  terminologies  are  provided  (Figure  1.  mid¬ 
dle  column). 

The  scheme  for  characterizing  product  and  process 
specifications  is  based  on  the  following  four  dimen¬ 
sions: 

1.  Purpose  and  context  (i.e.,  what  is  the  ex¬ 
pected  role  of  the  specified  product  or 
process  type?) 

2.  Content  (i.e.,  what  aspects  of  the  product 
or  process  type  need  to  be  described,  and 
with  what  attributes?) 
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3.  Representation  format  (i.e.,  what  models 
and  languages  should  be  used  to  repre¬ 
sent  the  above  content?) 

4.  Support  (i.e.,  what  methods  and  tools 
should  be  used  to  support  the  creation  of 
life-cycle  products  and  processes  accord¬ 
ing  to  the  above  representation  format?) 

The  first  two  dimensions  of  the  characterization 
scheme  are  used  to  identify  three  important  phases  in 
the  context  of  the  reference  life-cycle  model: 

1.  C-requirements  (customer/user-oriented 
requirements) 

2.  D-requirements  (developer-oriented  re¬ 
quirements) 

3.  Design 

These  reference  phases  are  discussed,  using  the 
framework,  not  because  the  author  believes  that  they 
are  more  important  than  other  phases,  but  because 
they  arc  likely  to  correspond  most  closely  to  the 
reader’s  intuitive  notion  of  “specification.” 

All  four  dimensions  of  the  characterization  scheme 
are  used  to  select  and  evaluate  specification  tech¬ 
niques.  Requirements  for  any  specification  tech¬ 
nique  arc  formulated  in  terms  of  the  latter  three 
dimensions  of  the  characterization  scheme, 
motivated  by  its  project-specific  purpose  and  con¬ 
text.  Selection  implies  finding  a  specification  tech¬ 
nique  that  matches  the  stated  requirements;  evalua¬ 
tion  implies  comparing  the  actual  effects  of  the  cho¬ 
sen  technique  to  the  expected  ones,  as  stated  in  the 
requirements. 

Relation  to  Other  Modules.  It  is  helpful  if  the 
reader  of  this  curriculum  module  is  familiar  with  SEI 
curriculum  modules  Models  of  Software  Evolution: 
Life  Cycle  and  Process  [Scacchi87]  and  Technical 
Writing  for  Software  Engineers  [Levine89]. 

Early  life-cycle  phases  are  often  given  less  attention 
in  the  classroom  than  are  later  phases,  such  as  de¬ 
sign,  coding,  and  testing,  even  though  their  impor¬ 
tance  is  widely  recognized.  It  is  hoped  that  the  in¬ 
sights  into  software  specifications  provided  here  will 
increase  the  understanding  of  teachers  and  allow 
these  activities  to  be  more  widely  taught. 

This  module  provides  material  needed  to  understand 
software  specifications  and  to  apply  that  understand¬ 
ing  to  the  characterization  of  specifications  and  to 
the  selection  and  evaluation  of  specification  tech¬ 
niques.  No  attempt  is  made  to  deal  with  system 
specifications  or  to  provide  detailed  guidance  about 
the  production  of  particular  life-cycle  products.  In¬ 
stead,  this  module  provides  background  for  more 


narrowly  focused  curriculum  modules,  which  utilize 
its  terminology.  Among  these  are  Software 
Requirements  [Brackett90],  addressing  C-  and  D- 
requirements,  and  Introduction  to  Software  Design 
[Budgen89],  dealing  with  design.  Additional  mod¬ 
ules  using  the  framework  set  forth  here  will  follow. 
This  module  should  be  studied  before  reading  any  of 
these  life-cycle-oriented  curriculum  modules. 


A  person  having  studied  the  material  covered  in  this 
curriculum  module  is  expected  to  be  able  to  do  the 
following: 

•  Explain  the  nature  of  the  confusion 
caused  by  the  common  uses  of  the  term 
“specification.” 

•  Apply  the  reference  life -cycle  model  and 
relate  its  terminology  to  that  of  any  of 
the  commonly  used  models. 

•  Discuss  C-rcquircments,  D-rcquiremcnts. 
and  design  within  the  framework 
presented  in  this  module. 

•  Apply  the  characterization  scheme  to  de¬ 
scribe  any  process  or  product  specifica¬ 
tion. 

•  Apply  the  characterization  scheme  to  the 
selection  of  specification  techniques. 

•  Apply  the  characterization  scheme  to  the 
evaluation  of  specification  techniques. 


In  order  to  understand  this  material,  the  student  must 
understand  the  fundamentals  of  software  engineering 
at  the  level  of  an  introductory  course  and  must  have 
had  practical  software  development  experience  as  a 
member  of  a  team. 


Objectives 


Prerequisite  Knowledge 
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Module  Content 


This  module  uses  the  terminology  in  [IEEE83]  where  1.  Selection  of  Proper  Specification  Techniques 

possible.  A  glossary  of  significant  terms  follows  the  a.  Define  specification  requirements 

annotated  outline.  .  ... 

b.  Chose  specification  techniques 

2.  Evaluation  of  Specification  Techniques 

VI.  Assessment  of  Current  Maturity  and  Future 
Outline  Directions 


I.  Overview 

1.  Conflicting  Meanings  of  “Specification” 

2.  Definition  Used  Here 

3.  A  Framework  for  Understanding  Specifications 

II.  A  Reference  Software  Life-Cycle  Model  and 
Terminology 

III.  A  Characterization  Scheme  for  Software 
Specifications 

1.  Purpose  and  Context 

a.  Product  perspective 

b.  Process  perspective 

c.  Use  perspective 

d.  People  perspective 

2.  Content 

a.  Aspects 

b.  Attributes 

3.  Representation 

a.  Models 

b.  Languages 

4.  Support 

a.  Methods 

b.  Tools 

IV.  A  Characterization  of  Life-Cycle  Phases 

1.  C-Requirements 

a.  Purpose  and  context 

b.  Content 

2.  D- Requirements 

a.  Purpose  and  context 

b.  Content 

3.  Design 

a.  Purpose  and  context 

b.  Content 

4.  Other  Object  Types 

V.  Guidelines  for  Selecting  and  Evaluating 
Specification  Techniques 


Annotated  Outline 


I.  Overview 

1.  Conflicting  Meanings  of  “Specification” 

The  term  “software  specification”  is  used  inconsis¬ 
tently  by  the  software  community.  Most  of  the  lime, 
it  refers  either  to  products  created  during  the  early 
phases  of  a  software  project,  to  the  processes  leading 
to  those  products,  or  to  descriptions/characteriza¬ 
tions  of  those  types  of  products  or  processes. 

2.  Definition  Used  Here 

Although  an  argument  can  be  made  for  referring  to 
diverse  types  of  products  and  processes  by  the  term 
“specification,”  a  compelling  argument  can  also  be 
made  for  restricting  the  term  in  order  to  avoid  con¬ 
fusion.  In  this  module,  we  will  avoid  completely 
use  of  the  term  for  any  of  the  usual  life-cycle  prod¬ 
uct  or  process  types.  Instead,  we  will  define 
software  specification  as  a  plan  or  standard  that  pro¬ 
vides  a  description/characterbation  of  a  software 
product  or  process  type.  This  definition  allows  us  to 
emphasize  “good”  software  engineering,  in  that  we 
focus  on  planning  before  execution. 

A  software  specification,  then,  becomes  a  product 
resulting  from  the  planning  process.  Execution  of 
the  “plan”  results  in  the  instantiation  of  a  particular 
product  or  process.  (See  Figure  2,  p.  21.)  A 
product  specification  describes  how  products  of 
some  type  should  look;  a  process  specification  de¬ 
scribes  how  processes  of  some  type  should  be  per¬ 
formed.  In  cases  where  planning  is  informal,  im¬ 
plicit,  or  haphazard,  specifications  are  not  explicitly 
constructed. 

Consider  software  design  as  an  example.  This  might 
involve: 

•  The  specification  of  the  input  product  type 
(requirements  product),  including  a  format 
syntax  and  semantics  description  for  the 
requirements  document,  or  a  standard. 
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such  as  ANSI/lEEE-Std-830  on  “software 
requirements  specification”  [IEEE84], 

•  The  specification  of  the  output  product 
type  (design  product),  including  a  formal 
syntax  and  semantics  description  for  the 
design  document. 

•  The  specification  of  the  process  type 
(design  process),  including  a  guideline  for 
the  use  of  specific  design  techniques,  such 
as  Structured  Design  or  object-oriented  de¬ 
sign. 

As  another  example,  consider  software  compilation, 
which  might  involve: 

•  The  specification  of  the  input  product  type 
(source  code  product),  including  the 
source  language  definition,  a  coding  style 
handbook,  and  a  language-oriented  editor. 

•  The  specification  of  the  output  product 
type  (object  code  product),  the  object  code 
definition. 

•  The  specification  of  the  process  type 
(compilation  process),  the  compiler  tool  it¬ 
self. 

Other  examples  of  process  specifications  arc  the 
DoD  2 167 A  standard  on  “software  development” 
[DoD88a]  and  the  DoD  2168  standard  on  “software 
quality  assurance  process”  [DoD88b], 

As  a  general  rule,  existing  specification  techniques 
— models,  languages,  methods,  and  tools  used  to  in¬ 
stantiate  specifications  into  life-cycle  products  or 
processes — are  better  suited  (e  g.,  are  more  formal) 
to  the  specification  of  (1)  software  product  types, 
rather  than  process  types,  and  (2)  types  used  in  later, 
rather  than  earlier,  life-cycle  phases. 

3.  A  Framework  for  Understanding  Specifications 

This  module  presents  a  comprehensive  framework 
for  understanding  software  specifications  and  related 
issues.  The  framework  includes: 

•  a  reference  life-cycle  model  and  terminol¬ 
ogy, 

•  a  characterization  scheme  for  software 
product  and  process  specifications, 

•  guidelines  for  using  the  characterization 
scheme  to  identify  clearly  certain  life- 
cycle  phases,  and 

•  guidelines  for  using  the  characterization 
scheme  to  select  and  evaluate  specification 
techniques. 

The  framework  provides  a  tool  for  understanding  the 
literature  and  provides  background  and  context  for 
other  specification-related  curriculum  modules  ( e.g ., 
[Brackett90]  and  [Budgen89]). 


Within  the  framework,  we  characterize  any  product 
or  process  specification  by 

•  the  purpose  and  context  of  the  specified 
product  or  process  type, 

•  the  content  of  the  type  of  product  or  proc¬ 
ess  of  interest, 

•  the  representauon  format  used  to  capture 
the  content,  and 

•  available  support  for  the  creauon  of  the 
life-cycle  products  or  execuuon  of  proc¬ 
esses  of  the  type  of  interest. 

The  characterization  scheme  can  be  used  to 

•  Characterize  the  specification  needs  of  a 
project 

•  Characterize  candidate  specification  tech¬ 
niques. 

•  Select  the  appropriate  specification  tech¬ 
niques  by  comparing  the  project  specifi¬ 
cation  needs  with  the  characteristics  of 
candidate  specification  techniques  to  find 
the  best  match. 

•  Evaluate  specification  techniques  used  by 
comparing  observed  characteristics  to  ex¬ 
pected  ones  and,  if  necessary,  suggest 
changes  for  future  projects. 

In  this  module,  we  will  use  the  reference  life-cycle 
model  and  characterization  scheme  to  identify 
clearly  several  important  life-cycle  phases  and  to  an¬ 
alyze  these  phases  within  our  framework. 

II.  A  Reference  Software  Life-Cycle  Model  and 
Terminology 

Many  different  software  life-cycle  models  exist  (e.g.. 
waterfall  [Royce70],  iterative  enhancement  [Basili75], 
spire'  [Boehm861,  and  prototyping  [Boehm84]).  Thev 
have  in  common  certain  types  of  products  (e.g  ,  re¬ 
quirements,  design,  code).  They  differ  substantially, 
however,  in  the  types  of  processes  used  to  build  those 
products.  From  this  observation,  we  may  construct  a 
reference  life-cycle  model  that  posits  the  existence  of 
certain  product  types  filling  specific  roles  within  a  soft¬ 
ware  development  context  but  that  makes  no  particular 
assumptions  about  the  mechanisms  by  which  products 
are  actually  built. 

Such  a  reference  life-cycle  model  is  shown  in  the 
leftmost  column  of  Figure  1,  p.  20,  where  we  assume 
the  existence  of  the  following  product  types  (we  do  not 
distinguish  between  deliverable  products  and 
documents): 

•  Software  needs ,  which  are  predominantly 

concerned  with  the  questions:  What  de¬ 
mands  exist?  What  needs  should  a  proposed 

software  product  attempt  to  fulfill? 

•  Customer/user-oriented  software  require- 
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merits  ( C-requirements ),  v  Inch  are  predomi¬ 
nantly  concerned  with  the  question:  What 
funcuonal  and  nonfunctional  characteristics, 
from  a  customer’s  or  user’s  point  of  view, 
must  a  pm  ; ■  <ct  exhibit  to  meet  those  needs ? 

•  Developer-oriented  software  requirements 
( D-reguirements),  which  arc  predominantly 
concerned  with  the  question:  What  funcuon¬ 
al  and  non-functional  characteristics,  from  a 
software  developer's  point  of  view,  must  a 
product  exhibit  to  meet  those  needs.1 

•  Software  design,  which  is  predominantly 
concerned  with  the  question:  How  can  a 
product  be  built  to  behave  as  described  by  the 
D  -requirements? 

•  Code ,  which  is  predominantly  concerned 
with  the  question:  How  is  the  product  ac¬ 
tually  implemented  on  some  machine  using  a 
particular  technology? 

The  reference  life-cycle  terminology  used  in  this  cur¬ 
riculum  module  is  depicted  in  the  rightmost  column  of 
Figure  1.  Whenever  possible,  we  refer  to  processes 
and  the  resulting  products  of  some  type  under  the  same 
name  (eg.,  “design  process"  and  "design  product'’). 
More  detailed  characterizations  of  the  product  and 
process  types  related  to  C-requircments.  D- 
requirements,  and  design  arc  contained  in  section  IV. 

Inconsistent  terminologies  are  used  in  different  indus¬ 
trial  software  development  organizations  and  in  the 
literature.  Examples  of  commonly  used  terms  are 
shown  in  the  middle  column  of  Figure  1.  The  reader 
may  map  his  or  her  preferred  or  local  terminology  (and 
associated  practice)  to  the  reference  terminology  as  re¬ 
quired.  Possible  inconsistencies  between  the  reader’s 
terminology  and  the  reference  life-cycle  terminology, 
along  with  resoluuons  enabling  the  application  of  our 
discussion  to  the  reader’s  circumstances,  include  the 
following: 

•  The  reader  uses  a  different  name  than  the  ref¬ 
erence  model  to  refer  to  the  same  product  or 
process  type.  Resolution  is  straightforward 
here,  of  course,  as  the  reader  can  simply  sub- 
sutute  one  name  for  another.  For  example, 
the  reader  may  prefer  using  the  term 
“requirements  definition”  to  refer  to  what  we 
call  “C-requirements  product.”  The  entire 
discussion  of  “C-requirements  products"  in 
this  module  applies  to  “requirements 
definitions,”  according  to  the  reader’s  termi¬ 
nology. 

•  The  reader  identifies  several  types  that  col¬ 
lectively  encompass  one  or  more  product  or 
process  types  of  the  reference  model,  or  vice 
versa,  and  a  1-1  mapping  is  not  possible.  In 
this  situation,  a  more  complex  mapping  is 
needed.  For  example,  in  the  reader’s  termi¬ 
nology  two  product  types,  “behavioral 


specification”  and  “functional  specification,” 
may  play  the  same  role  as  our  “D- 
requirements  product.”  The  entire  discussion 
related  to  '  D-requirements  products”  in  this 
module  applies  to  both  “behavioral 
specifications"  and  “functional  specifica¬ 
tions." 

•  Due  to  the  structural  model  chosen  tor  the 
deliverable  product,  the  reader  deals  with 
several  instances  of  a  product  or  process  type 
of  the  reference  model.  In  this  case,  multiple 
types  may  be  distinguished  with  appropriate 
qualifiers  and  treated  as  instances  of  types 
described  in  this  module.  For  example,  if  the 
product  is  structured  into  system,  subsystems, 
and  modules,  the  reader  may  identify  a  cor¬ 
responding  number  of  instances  of  types  de¬ 
sign  product  and  design  process. 

III.  A  Characterization  Scheme  for  Software 
Specifications 

This  section  incorporates  ideas  from  [AbbcttS5j. 
[SommerviHe89],  [FirthST],  and  elsewhere.  The  scheme 
presented  enables  the  characterization  of  any  software 
product  or  process  specification  in  terms  of  the  purpose 
and  context  of  the  specified  product  or  process  type, 
the  content  of  the  specified  type,  the  representauon 
used,  and  the  support  for  product  creauon  or  process 
execution. 

1.  Purpose  and  Context 

Specificauons  describe  all  important  characteristics 
of  a  particular  software  product  or  process  type  in 
some  format.  The  desirable  characteristics,  as  well 
as  the  appropriate  format  for  represenung  them,  are 
determined  by  the  purpose  and  context  of  the  type 
within  the  software  development  project.  We  have 
chosen  to  characterize  purpose  and  context  (in  no 
particular  order)  from  product,  process,  use,  and 
people  perspectives. 

a.  Product  perspective 

Product  and  process  specifications  are  ulumately 
aimed  at  creating  life-cycle  products  (i.e..  project 
deliverables)  to  satisfy  the  customer.  Therefore, 
it  is  assumed  that  the  choice  ot  product  and  proc¬ 
ess  specificauons  depends  on  the  type  of 
deliverables  to  be  developed.  We  characterize 
product  types  by  application  and  quality  require¬ 
ments. 

(i)  Application 

The  type  of  application  has  a  deep  impact  on 
what  product  or  process  aspects  (see  sccuon 
III. 2. a)  need  to  be  specified.  There  arc  a  num¬ 
ber  of  possible  classification  schemes  for  soft¬ 
ware  applications,  for  example: 

•  schemes  based  on  control-flow  char- 
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acteristics  of  the  software  system 
(sequential,  concurrent,  real-time) 

•  schemes  based  on  the  application 
(commercial,  system,  process  con¬ 
trol,  scientific,  embedded) 

(ii)  Quality  requirements 

The  need  to  satisfy  particular  software  quality 
requirements  impacts  both  the  aspects  that 
need  to  be  specified  and  their  attributes  (see 
sections  111.2.a-b).  For  example,  the  need  for 
maintainability  may  justify  the  explicit  specifi¬ 
cation  of  the  design  rationale  in  a  traceable 
form,  so  maintaincrs  can  trace  changed  require¬ 
ments  to  affected  design  components. 

An  incomplete  list  of  possible  quality  require¬ 
ments  includes: 

•  reliability 

•  correctness 

•  fault-tolerance 

•  maintainability 

•  portability 

•  user-friendliness 

•  availability 

b.  Process  perspective 

Specifications  serve  different  purposes  in  differ¬ 
ent  development  process  contexts.  We  charac¬ 
terize  the  process  perspective  in  terms  of  the 
overall  life-cycle  model  and  its  individual  life- 
cycle  phases. 

(i)  Life-cycle  models 

Different  lifc-cycle  models,  reflecting  different 
philosophies  for  creating  software  products,  in¬ 
corporate  different  product  and  process  types 
[Scacchi87], 

(1)  Waterfall  model 

The  waterfall  model  [Royce70]  is  based  on 
the  idea  of  producing  product  types  at  differ¬ 
ent  levels  of  abstraction  (requirements,  sys¬ 
tem  design,  module  designs,  code)  sequen¬ 
tially,  followed  by  the  integration  of  code  in 
reverse  order.  Following  this  model  in  a 
project  means  transforming,  in  a  linear  fash¬ 
ion,  the  entire  set  of  requirements  into  more 
and  more  concrete  solutions.  Attempting  to 
feed  lessons  learned  back  into  earlier  stages 
results  in  (acceptable)  deviations  from  the 
waterfall  model.  It  must  be  remembered 
that  the  waterfall  model  is  just  a  model , 
which  is  intended  to  stress  the  top-down 
principle  for  software  development.  In  prac¬ 
tice,  there  exist  many  exceptions  to  this  se¬ 


quential  paradigm,  reflecting  the  fact  that  er¬ 
rors  are  committed  in  the  application  of  this 
principle. 

(2)  Iterative  enhancement  model 

The  iterative  enhancement  model  [Basili75] 
is  based  on  the  idea  of  producing  the  same 
product  types  as  for  the  waterfall  model  for 
only  some  of  the  requirements  at  a  time.  The 
idea  is  to  allow  for  more  effective  1  aming- 
based  feedback  from  each  of  these  “mini¬ 
development”  projects  or  to  allow  feasibility 
analysis  of  some  critical  requirements  (by 
actually  implementing  them)  before  commit¬ 
ting  to  the  entire  project.  The  product  types 
used  according  to  the  iterative  enhancement 
model  might  be  the  same  used  according  to 
the  waterfall  model.  However,  the  process 
types  (or  at  least  the  instantiation  patterns) 
arc  very  different. 

(3)  Prototyping  model 

The  prototyping  model  [Boehm84]  is  based 
on  first  concentrating  on  producing  an  oper¬ 
ational  software  version  for  a  limited  set  oi 
the  overall  requirements.  This  limited  set  of 
requirements  excludes  part  of  the  functional 
or  non-functional  overall  requirements. 
Very  often,  crucial  man-machine  interface 
requirements  or  highly  demanding  perfor¬ 
mance  requirements  are  the  reason  for 
prototyping.  Prototyping  is  intended  to  help 
in  the  process  of  developing  an  acceptable 
C-  or  D-requirements  product  or  to  explore 
the  technical  feasibility  of  requirements  and 
the  associated  risk.  Prototyping  is  a  way  of 
learning  “fast”  about  crucial  project  issues. 
The  expectation  is  that  this  up-front  invest¬ 
ment  pays  off  either  by  detecting  early  on 
that  it  is  infeasible  to  continue  the  project  or 
by  creating  an  acceptable  C-  or  D- 
requirements  product  that  allows  predictable 
and  controllable  software  evolution.  The 
goal  is  only  to  reuse  the  experience  gained 
during  the  prototyping  process  and  feed  it 
back  into  creating  better  requirements,  not 
necessarily  to  reuse  any  products  created  as 
part  of  the  prototyping  process.  After  ac¬ 
ceptable  requirements  have  been  created,  the 
regular  software  evolution  process  can  fol¬ 
low  any  other  life-cycle  model  ( e.g ., 
waterfall). 

(4)  Spiral  model 

The  spiral  model  [Boehm86]  is  based  on  a 
risk -driven  approach  to  software  evolution. 
Iterative  development  cycles  are  organized 
in  a  spiral  manner,  with  inner  cycles 
representing  early  analysis  and  prototyping. 
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and  outer  cycles  representing  the  classic  sys¬ 
tem  life  cycle.  This  technique  is  combined 
with  risk  analysis  during  each  cycle.  The 
mocM  is  intended  to  identify  situations  that 
might  cause  a  development  effort  to  fail  or 
go  over  budget  or  schedule.  The  spiral  tech¬ 
nique  incorporates  ideas  derived  from  the  it¬ 
erative  enhancement  model  and  the 
prototyping  model. 

(ii)  Life-cycle  products  and  processes 

Product  and  process  specifications  are  created 
for,  used  in,  affected  by,  and  modified  during 
particular  phases.  These  phases  include,  ac¬ 
cording  to  our  life-cycle  reference  model: 

•  software  needs 

•  C-requirements 

•  D-requircments 

•  software  design 

•  code 

Additional  project  phases  may  include: 

•  verification  and  validation  [Collo- 
fello88] 

•  integration 

•  maintenance 

•  teaching  and  training 

c.  Use  perspective 

There  exist  a  variety  of  different  uses  for  specifi¬ 
cations.  We  distinguish  between  uses  for  com¬ 
munication,  creation,  modification,  verification 
and  validation,  and  software  quality  assurance. 

(i)  Communication  among  people 

Software  projects  include  people.  Specifica¬ 
tions  are  aimed  at  supporting  their  communi¬ 
cations  regarding  the  important  product  and 
process  characteristics  and  guidelines  accord¬ 
ing  to  which  products  are  created  and  modi¬ 
fied,  and  processes  are  executed  and  changed. 
Specifications  are  a  useful  mechanism  for 
teaching  and  training  people  what  products 
should  look  like  and  how  processes  should  be 
executed  Also,  the  existence  of  specifications 
allows  project  members  to  achieve  reliable 
consensus  about  their  roles  by  making  explicit 
the  project's  purpose,  context,  and  procedures. 

(ii)  Creation  of  products 

Many  software  project  tasks  are  aimed  at  creat¬ 
ing,  in  a  traceable  way,  instances  of  one  prod¬ 
uct  type  from  instances  of  another  (e.g.,  a  de¬ 
sign  product  from  a  D-rcquirements  product). 
Explicit  specifications  for  both  product  types 
and  for  the  creating  process  (the  design  proc¬ 


ess,  in  this  case)  help  guide  and  control  the 
task.  If  all  three  specifications  are  completely 
formal  (see  [Berztiss87]),  the  desired  product 
can  be  created  automatically.  In  the  best  cur¬ 
rent  practice,  most  product  types  are  explicitly 
specified,  whereas  most  process  types  are  not. 
Further,  downstream  product  types  tend  to  be 
defined  with  greater  formality  that  early-phase 
ones.  The  degree  of  formality  and  specificity 
in  a  process  specification  (or  the  lack  thereof) 
is  indicative  of  the  possible  degree  of  guidance 
and  control.  Process  specifications  can  be  used 
by  people  (e.g.,  a  designer  uses  a  set  of  infor¬ 
mal  design  guidelines)  or  by  automated  tools 
(e.g.,  a  compiler  uses  a  formally  specified  pro¬ 
cedure  for  transforming  source  code  into  object 
code). 

(iii)  Modification  of  products  and  processes 

Software  projects  require  the  ability  to  react  to 
changes.  Changing  product  requirements  dur¬ 
ing  development  or  enhancement  requests  dur¬ 
ing  maintenance  typically  requires  modifica¬ 
tions  to  existing  products,  with  or  without 
changing  the  underlying  product  specification. 
Changing  project  or  environment  characteris¬ 
tics  (e.g.,  addition  of  new  personnel  or  intro¬ 
duction  of  new  technology)  may  require 
modifications  to  existing  processes  and  pos¬ 
sibly  to  their  underlying  specifications.  The 
existence  of  explicit  product  and  process  speci¬ 
fications  permits  the  incorporation  of  changes 
in  a  systematic  way. 

(iv)  Verification  and  validation  products 

The  purpose  of  verification  and  validation 
(V&V)  is  to  show  that  a  life-cycle  product  of 
some  type  (e.g.,  source  code)  is  consistent  with 
a  life-cycle  product  of  a  different  type  (e.g., 
design  product)  [Collofello88],  This  kind  of 
cross-checking  between  products  is  facilitated 
by  the  existence  of  explicit  specifications. 

(v)  Assuring  adherence  to  plans 

Software  quality  assurance  (SQA)  is  concerned 
with  assuring  that  software  development  is  car¬ 
ried  out  according  to  plan  [Brown87],  Much  of 
the  concern  of  SQA,  then,  is  with  comparing 
software  products  and  processes  to  their  speci¬ 
fications.  Examples  are  checking  whether  a 
design  product  is  consistent  with  its  specifica¬ 
tion  or  whether  a  review  process  was  con¬ 
ducted  according  to  established  review  guide¬ 
lines. 

d.  People  perspective 

Specifications  are  created  or  used  by  audiences 

playing  different  project  roles.  Although  some 

specifications  are  intended  for  consumption  by 
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machines,  people  have  to  understand  them  in  one 
way  or  another.  Examples  of  different  project 
audiences  are  listed  below.  (Some  of  the  descrip¬ 
tions  are  adopted  from  [Firth87].) 

(i)  Customers 

The  audience  that  contracts  for  the  software 
project  and,  in  part,  determines  the  C- 
requirements  for  the  system. 

(ii)  End-users 

The  audience  that  will  install,  operate,  use,  and 
maintain  the  system  after  it  is  delivered,  and 
that,  in  part,  determines  the  C-requirements  for 
the  system. 

(iii)  Sub-contractors 

The  audience  that  performs  development  or 
maintenance  activities  contracted  out  by  the 
primary  development  organization. 

(iv)  Requirements  analysts 

The  audience  that  develops  the  C-rcquircments 
product  in  conjunction  with  the  customers  and 
end-users.  Requirements  analysts  find  a  repre¬ 
sentation  format  appropriate  to  customer  and 
end-user  needs. 

(v)  Specification  engineers 

The  audience  that  evolves  the  C-requixements 
product  into  the  D-rcquiremcnts  product.  The 
main  objectives  of  specification  engineers  are 
to  resolve  ambiguities,  remove  inconsistencies, 
and  represent  the  D-requirements  in  a  format 
suitable  for  the  development  audiences.  This 
often  implies  use  of  more  formal  represen¬ 
tations  for  D-requirements  than  C- 
requirements. 

(vi)  Designers 

The  audience  that  describes  how  the  software 
system  is  to  be  constructed  to  satisfy  the  cor¬ 
responding  D-requirements  product.  This  in¬ 
volves  making  optimization  decisions  about 
the  best  way  to  proceed,  given  the  constraints 
imposed  in  the  D-requirements  product.  Ex¬ 
amples  of  such  constraints  are  performance  re¬ 
quirements,  resources  available,  and  fault- 
tolerance  capabilities.  These  constraints  often 
influence  the  design  as  much  as  the  required 
behavior  of  the  system. 

There  are  basically  two  types  of  design  proc¬ 
esses:  (1)  designing  a  system  that  consists  of  a 
set  of  communicating  components  and  deter¬ 
mining  the  functionality  of  the  components, 
and  (2)  designing  the  algorithms  ana  data 
structures  encapsulated  in  those  components. 


(vii)  Implementors 

The  audience  that  takes  the  component  design 
products  and  develops  the  corresponding  im¬ 
plementation  products  (code). 

(viii)  V&V  personnel 

The  audience  that  checks  whether  life-cycle 
products  are  consistent  with  earlier  life-cycle 
products. 

(ix)  SQA  personnel 

The  audience  that  checks  whether  life-cycle 
products  are  created  and  life-cycle  processes 
performed  according  to  their  specifications. 

(x)  Configuration  management  personnel 

The  audience  that  assures  the  integrity  of  soft¬ 
ware  during  and  after  development  by  initiat¬ 
ing,  evaluating,  and  controlling  changes  to  the 
product  [Tomayko87], 

(xi)  Maintenance  personnel 

The  audience  that  keeps  the  software  system 
operational  and  useful.  Maintenance  personnel 
perform  corrective,  perfective,  and  adaptive 
maintenance  activities. 

(xii)  Managers 

The  audience  concerned  with  filling  leadership 
roles,  controlling  the  budgets  and  schedules  re¬ 
lated  to  the  project,  ensuring  that  problems  are 
recognized  and  resolved  early,  and  dealing 
with  personnel  assignments  and  problems. 

2.  Content 

We  characterize  a  specification  also  by  its  content, 
that  is,  by  the  product  or  process  aspects  it  addresses 
and  by  attributes  to  be  possessed  by  the  represen¬ 
tation  of  those  aspects. 

According  to  this  view,  the  roles  of  product  and 
process  specifications  are  not  completely  parallel. 
To  begin  with,  mechanisms  for  specifying  process 
types  are  much  less  developed  than  those  for  speci¬ 
fying  product  types.  (More  on  this  below.)  More 
fundamentally,  however,  instantiation  of  a  process 
specification  produces  action,  whereas  that  of  a 
product  specification  produces  a  static  artifact,  albeit 
one  either  capable  of  animation  ( i.e .,  execution)  or 
descriptive  of  another  artifact  with  such  a  capability. 
Despite  this  difference,  we  will  treat  products  and 
processes  in  parallel;  examples  will  clarify  the  dif¬ 
ferences  wherever  applicable. 

a.  Aspects 

Four  important  aspects  that  may  be  addressed  in  a 
specification  are  behavior,  interface,  flow,  and 
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structure  of  the  objects  (products  or  processes) 
specified.  To  discuss  these,  we  First  introduce 
several  definitions. 

Dynamic  characteristics  of  an  object  of  any  type 
relate  to  its  use.  Dynamic  characteristics  of  a 
process  can  be  captured  during  its  execution  (e.g., 
the  set  of  all  design  decisions  made  by  a  designer 
or  historical  data  on  the  amount  of  time  required 
for  design  on  past  projects).  Dynamic  character¬ 
istics  of  a  product  can  be  captured  during  its  oper¬ 
ational  use  by  the  customer/user  or  during  its  test¬ 
ing  phase. 

Static  characteristics  of  an  object  of  any  type  re¬ 
late  to  its  representation.  Static  characteristics  of 
a  process  should  be  described  in  its  specification 
(e.g.,  the  steps  in  a  design  process).  Static  aspects 
of  a  product  are  described  in  the  product  itself  and 
in  its  specification  (e.g.,  data  structures  or  al¬ 
gorithmic  control  structure  of  an  Ada  source  code 
product). 

Functional  characteristics  of  an  object  of  any  tj  pc 
relate  to  its  functional  requirements.  These  can 
be  identified  by  analyzing  what  services  are  pro¬ 
vided  by  the  object  (e.g.,  functions  such  as  “store” 
and  “retrieve”  provided  by  a  product;  generation 
of  a  product  of  type  “design”  by  a  process). 

Non-functional  characteristics  of  an  object  of  any 
type  relate  to  its  non-functional  requirements. 
These  can  be  idenufied  by  analyzing  how  services 
are  provided  by  the  object  (e.g.,  each  of  the  above 
product  functions  must  be  provided  in  time  less 
than  t;  the  product  of  type  “design”  must  be  pro¬ 
duced  by  the  above  process  within  a  certain 
period  of  time  and  within  a  certain  budget). 

External  characteristics  of  an  object  of  any  type 
relate  to  the  black-box  view  of  that  object.  Exter¬ 
nal  characteristics  of  an  object  can  be  identified 
without  knowledge  of  its  actual  implementation 
(e.g.,  a  product  provides  certain  interface  func¬ 
tions  or  reacts  to  certain  input  stimuli  in  particular 
ways;  a  process  consumes  certain  inputs  and  pro¬ 
duces  certain  output  products). 

Internal  characteristics  of  an  object  of  any  type 
relate  to  the  white-box  view  of  that  object.  Inter¬ 
nal  characteristics  of  an  object  are  identified 
based  on  knowledge  of  its  actual  implementation 
(e.g.,  a  product  contains  a  number  of  modules 
with  certain  bindings  among  them;  a  process  con¬ 
sists  of  a  number  of  subprocesses). 

We  now  use  these  definitions  to  characterize,  ex¬ 
plain,  and  distinguish  aspects  of  products  and 
processes  we  may  wish  to  address  in  specifica¬ 
tions. 


(i)  Behavior  (external,  dynamic) 

The  externally  observable  response  of  a  prod¬ 
uct  or  process  to  stimuli  in  actual  use.  Be¬ 
havior  may  include  externally  observable 
states,  outputs,  or  boundary  conditions  on  the 
validity  of  inputs  and  states.  We  distinguish 
between  functional  and  non-functional  be¬ 
havioral  aspects. 

(1)  Functional  behavior 

This  may  include  the  response  of  a  product 
to  specific  inputs  or  the  requirement  that  a 
certain  pre-condition  of  a  process  results 
(after  execution)  in  a  certain  post-condition. 

(2)  Non-functional  behavior 

This  may  include  response  time  of  a  product 
or  the  time  allowed  for  completion  of  a 

process. 

(ii)  Interface  (external,  static) 

The  structure  of  the  boundary  between  product 
or  process  and  its  environment.  We  distinguish 
between  functional  and  non-functional  inter¬ 
face  aspects. 

(1)  Functional  interface 

This  may  include  the  set  of  functions  pro¬ 
vided  by  a  product  or  the  role  a  process 
plays  in  software  development. 

(2)  Non-functional  interface 

This  may  include  response-time  constraints 
on  a  product  or  a  description  of  the  required 
synchronization  points  of  a  process  with 
other  processes. 

(iii)  Flow  (internal,  dynamic) 

The  internal  dynamics  of  a  product  or  process 
in  actual  use.  This  may  include  the  flows  of 
control,  data,  and  information  between  struc¬ 
tural  units  of  the  product  or  process.  (The  dif¬ 
ference  between  control  flow,  data  flow,  and 
information  flow  is  nicely  explained  in 
[HenrySI].)  In  the  case  of  parallel  processes, 
we  must  also  consider  such  aspects  as 
synchronization.  We  distinguish  among  the 
following: 

(1)  Control  flow  between  sub- products  or 
sub-processes 

(2)  Data  flow  between  sub-products  or 
sub-processes 

(3)  Information  flow  between  sub-products 
or  sub-processes 

(4)  Synchronization  between  executing 
sub-products  or  sub-processes 
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(iv)  Structure  (internal,  static) 

The  organization  of  a  product  or  process  into 
interacting  parts.  This  includes  the  decomposi¬ 
tion  of  the  whole  into  components  or  the  com¬ 
position  of  the  whole  from  basic  units.  Ar¬ 
chitectural,  algorithmic,  and  data  structures,  as 
well  as  the  internal  interfaces  between  sub¬ 
structures,  may  be  of  interest.  We  distinguish 
among: 

(1)  Architectural  structure  of  a  product  or 
process  in  terms  of  sub-products  or 
sub-processes 

(2)  Interfaces  between  sub-products  or 
sub-processes 

(3)  Algorithmic  structure  of  a  product  or 
process 

(4)  Data  structures  used  in  a  product  or 
process 

(5)  Information  structure  across 
sub-products  or  sub-processes 

b.  Attributes 

In  general,  each  of  the  aspects  in  (a)  can  be 
represented  in  a  variety  of  different  forms.  Pur¬ 
pose  and  context  of  the  product  or  process  type  of 
interest  require  a  suitable  form  of  representation 
to  exhibit  certain  attributes. 

For  example,  if  the  aspect  “data  flow”  of  a  design 
product  needs  to  be  validated,  we  may  specify 
that  its  representation  needs  to  exhibit  the  attri¬ 
butes  “complete,”  “consistent,”  and  “executable.” 
If  the  “control  flow”  of  a  design  process  needs  to 
be  validated,  we  may  specify  that  its  represen¬ 
tation  needs  to  exhibit  the  attribute  “executable.” 

(i)  Correctness 
Requirements  are  satisfied. 

(ii)  Completeness 

All  relevant  information  is  captured. 

(iii)  Consistency 

There  are  no  internal  or  external  contradictions. 

(iv)  Feasibility 

Requirements  are  satisfied  within  the  con¬ 
straints  imposed  by  the  software  evolution  con¬ 
text. 

(v)  Non-ambiguity 

Alternative  interpretations  are  not  possible. 

(vi)  Clarity 

The  meaning  of  the  representation  is  easily  un¬ 
derstood  and  communicated. 

SEI-CM-1 1-2.1 


(vii)  Preciseness 
The  meaning  is  exact. 

(viii)  Formality 

Formal  syntax  and  semantics  are  used. 
Various  degrees  of  formality  are  possible. 
Mathematical  formalism  is  the  subject  of 
[Berztiss87],  [Bjorner82],  [IWSSD82], 
[1WSSD84],  [IWSSD85],  and  [1WSSD87], 

(ix)  Abstractness 

The  description  is  at  a  particular  level  of  ab¬ 
straction.  D-requirements  are  more  abstract 
(removed  from  the  details  of  the  eventual 
implementation)  than  code. 

(x)  Structuredness  (or  modularity) 

The  description  shows  systematic  structure. 
Lessons  learned  regarding  the  production  of 
readable  code  by  applying  the  concepts  of 
modularization  and  minimizing  interfaces  be¬ 
tween  modules  should  be  applied  to  specifi¬ 
cations  of  all  types  of  products  and  processes. 

(xi)  Traceability 

One  is  able  to  relate  information  items  of  cor¬ 
responding  product  or  process  types.  For  ex¬ 
ample,  a  C-requirements  product  is  much  more 
helpful  in  the  context  of  maintenance  if  it  is 
possible  to  trace  changes  made  to  the  D- 
requirements  to  certain  components  described 
in  the  architectural  design  product. 

(xii)  Modifiability 

Changes  can  be  made  easily  whenever  neces¬ 
sary  (e.g.,  during  maintenance). 

(xiii)  Executability 

The  attribute  of  being  automatically  executable 
on  some  machine.  This  characteristic  allows 
for  validating  the  dynamic  and  behavioral  char¬ 
acteristics;  the  executability  of  more  abstract 
products  (e.g.,  D-requirements)  underlies  the 
quick-feedback  idea  of  prototyping. 

(xiv)  Verifiability 

Techniques  (possibly  formal)  can  be  used  to 
check  for  consistency  with  requirements. 

3.  Representation 

Certain  software  aspects  (see  m.2.a)  need  to  be 
represented  so  they  exhibit  desired  attributes  (see 
III.2.b).  The  representation  format  chosen  is  based 
on  models  and  languages.  Models  allow  the  for¬ 
mulation  of  aspects  of  interest.  Languages  allow  the 
well-defined  reflection  of  those  models  in  a  form 
that  exhibits  the  desired  attributes.  We  make  the 
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distinction  between  models  and  languages  to  express 
the  different  formal  representational  capabilities.  In 
practice,  however,  it  is  not  always  easy  to  distin¬ 
guish  between  models  and  languages. 

Our  discussion  may  seem  to  be  biased  toward  prod¬ 
ucts,  rather  than  processes.  In  fact,  despite  the  rec¬ 
ognized  need  for  representing  “process,”  most 
people  use  traditional  product  languages  for  the  pur¬ 
pose.  It  is  currently  a  burning  research  issue  to  iden¬ 
tify  appropriate  mechanisms  for  process  represen¬ 
tations.  ( E.g .,  see  the  annual  proceedings  of  the  In¬ 
ternational  Software  Process  Workshop,  which  are 
usually  published  as  special  issues  of  ACM 
SIGSOFT’s  Software  Engineering  Notes.) 

a.  Models 

Specification  models  allow  the  formulation  of  and 
reasoning  about  certain  aspects  of  interest 

An  incomplete  list  of  examples  includes: 

•  functional  models 

•  input-output  models  [Ross77] 

•  algebraic  models  [Guttag78] 

•  axiomatic  models  [Hoare69] 

•  finite  state  models  [Parnas72] 

•  statecharts  [Harel88a] 

•  stimulus-response  models  [Alford77] 

•  Petri  net  models  [Peterson77,  8runo86, 
Peterson81] 

•  control  flow  models 

•  constraint  models 

•  module  interconnection  models  [De- 
Remer76] 

•  data  structure  models 

•  information  flow  models 

•  information  structure  models 

•  requirements  net  models  [Alford77] 

•  data  flow  models  [Babb85] 

•  entity-relationship  models 

•  relational  models  [Teichrow77] 

b.  Languages 

Specification  languages  allow  the  presentation  of 
specifications  in  a  well-defined  fashion  (Bal- 
zer81].  It  is  impossible  to  give  a  complete  list  of 
such  languages;  there  are  just  too  many.  Most  of 
them  allow  the  representation  of  more  than  one 
aspect  of  the  thing  specified.  For  example,  an 
implementation  language  such  as  Ada  allows  rep¬ 
resentation  based  on  control  flow,  data  flow,  and 
data  structure  models.  Instead,  we  provide  a 
characterization  of  existing  languages  based  on 
whether  they  are  formal  or  semi-formal  or  infor¬ 


mal,  whether  they  are  textual  or  graphical,  and  the 
language  paradigm  on  which  they  are  based. 

We  distinguish  between  formal,  semi-formal,  and 
informal  languages: 

•  Formal  languages  are  based  on  formal 
syntax  and  semantics  [Berztiss87]. 

•  Semi-formal  languages  are  based  on 
some  formal  syntax  and  are  usually 
graphically  oriented. 

•  Informal  languages  are  usually  based  on 
natural  language. 

Most  of  the  product  (and  process)  specification 
languages  used  in  practice  are  semi-formal  lan¬ 
guages,  combining  formal  and  informal  elements. 
Most  are  based  on  a  conceptual  specification 
model,  a  specific  representation,  or  a  develop¬ 
ment  approach. 

We  distinguish  between 

•  tabular , 

•  textual ,  and 

•  graphical 

representation  languages. 

We  also  distinguish  between  different  language 
paradigms.  Some  important  examples  are: 

•  imperative 

•  declarative 

•  constraint  oriented 

•  data-flow  oriented 

The  reader  interested  in  different  language 
paradigms  is  referred  to  any  classical  program¬ 
ming  language  book. 

4.  Support 

In  practice,  it  is  necessary  to  have  effective  support 
for  creating  specifications,  as  well  as  for  using  them 
during  project  execution.  Most  existing  support  ac¬ 
tually  addresses  the  instantiation  of  products  accord¬ 
ing  to  product  specifications.  We  distinguish  be¬ 
tween  methods  that  provide  operational  guidelines 
based  on  some  models  and/or  languages,  and  the 
automation  of  those  guidelines  using  computers. 
There  exists  a  m-to-n  relationship  between  methods 
and  tools.  One  method  can  be  supported  by  an  inte¬ 
grated  set  of  tools,  a  single  tool,  or  several  tools 
alternatively.  Correspondingly,  a  tool  may  support 
part  of  a  method,  an  entire  method,  or  several  inte¬ 
grated  methods. 

a.  Methods 

Popular  examples  include: 

•  SREM  [Alford77] 

•  Jackson  Methodology  [Cameron89, 
Sutcliffe88,  Cohen86] 
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•  SADT  [Ross77] 

•  PSL  [Teichrow77] 

•  Structured  Analysis  [DeMarco79,  Your- 
don89] 

•  Real-time  specification  methods  [Rzep- 
ka85,  Hatley87] 

These  methods  are  discussed  in  detail  in  relevant 
SEI  curriculum  modules  ( e.g .,  SA,  SADT,  and 
SREM  in  [Brackett90]). 

b.  Tools 

Popular  examples  include: 

•  PSA  [Teichrow77] 

•  REVS  [Alford77] 

•  compilers  and  runtime  environments  for 
all  kinds  of  languages  [Goidsack85] 

•  Statemate  [Harel88b] 

These  tools  will  be  discussed  in  detail  in  the  ap¬ 
propriate  curriculum  modules. 

IV.  A  Characterization  of  Lifc-Cyclc  Phases 

In  this  section,  the  characterization  scheme  of  section 
III  is  used  to  define  some  of  the  phases  within  the 
reference  life-cycle  model  of  section  II.  We  will  pro¬ 
vide  definitions  of  C-requirements,  D-rcquirements, 
and  design  based  on  the  purpose/context  dimension 
(section  III.  1)  and  the  content  dimension  (section 
III.2.a)  of  the  characterization  scheme.  Figures  3a  and 
3b  allow  for  the  graphical  representation  of  such 
definitions.  First,  we  characterize  the  purpose/context 
of  a  specification  within  some  software  evolution  proc¬ 
ess  (vertical  axis  in  Figure  3a).  Second,  we  derive  the 
aspects  that  need  to  be  described  based  on 
purpose/context  (horizontal  axis  in  Figure  3a).  Third, 
we  define  desirable  attributes  for  each  aspect  (vertical 
axis  in  Figure  3b),  considering  also  purpose/context. 
Marked  matrix  elements  in  Figures  3a  and  3b  provide  a 
graphical  representation  of  the  scope  of  the  correspond¬ 
ing  life-cycle  phases  of  interest. 

These  definitions  help  us  define  particular  software  de¬ 
velopment  activities  and  serve  to  delineate  the  bounds 
of  related  curriculum  modules,  such  as  those  on  re¬ 
quirements  analysis  [Brackett90]  and  design 
[Budgen89]. 

1.  C-Requirements 

C-requirements  are  predominantly  concerned  with 
answering  the  question  what  functional  and  non¬ 
functional  characteristics,  from  a  customer'  si  user' s 
point  of  view,  must  a  software  product  exhibit?  This 
section  characterizes  products  of  type  C- 
requirements,  using  the  characterization  scheme  in¬ 
troduced  in  section  III  (partly  reflected  in  figure  4). 
Processes  of  type  C-requirements  are  is  treated  in 
[Brackett90], 


a.  Purpose  and  context 

The  purpose  and  context  of  products  of  type  C 
requirements  can  be  characterized  as  follows: 

•  Product  Perspective:  For  our  purposes 
here,  we  generalize  across  all  possible 
application  domains  and  quality  require¬ 
ments. 

•  Process  Perspective:  For  our  purposes 
here,  we  generalize  across  all  possible 
life-cycle  models.  We  are  interested  in 
product  and  process  types  related  to 
overall  system  requirements  and  their 
validation. 

•  Use  Perspective:  C-requirements  serve 
as  a  basis  for  communication  with  the 
customer  and  end-user.  They  define,  in 
a  contractual  sense,  what  functions  a 
software  system  must  fulfill.  In  addi¬ 
tion,  they  serve  as  input  product  for  the 
subsequent  creation  of  the  D- 
requirements,  as  reference  document  for 
acceptance  testing  (V&V),  and  as  the 
potential  starting  point  for  maintenance 
activities  (especially  in  the  case  of  per¬ 
fective  maintenance).  The  C- 
requirements  product  is  derived  from 
software  needs;  created  during  the  C- 
requirements  process;  used  during  de¬ 
sign,  verification  and  validation,  and 
maintenance  activities;  and  modified 
throughout  the  entire  lifetime  of  the  cor¬ 
responding  software  system. 

•  People  Perspective:  C-requirements 
are  used  by  customers  and  end-users, 
requirements  analysts,  specification  en¬ 
gineers,  verification  and  validation 
people,  quality  assurance  personnel, 
maintenance  personnel,  and  managers. 

b.  Content 

The  content  of  C-requirements  can  be  charac 
terized  as  follows: 

•  Aspects:  C-requirements  address  the 
aspects  behavior  and  interface,  insofar 
as  they  are  important  to  establish  a  con¬ 
tractual  relationship  with  the  customer 
and  user.  Sometimes  even  structural  as¬ 
pects  (i.e.,  design  constraints)  have  to 
be  addressed  if  they  are  essential  to 
product  creation  (e.g.,  in  the  case  of  a 
specific  technical  process  that  needs  to 
be  controlled). 

C-requirements  can  suffer  from  over¬ 
specification,  as  well  as  under- 
specification.  Of  course,  it  is  desirable 
to  describe  all  aspects  that  are  of  inter¬ 
est  to  the  customer  and  user  as  com- 
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pletely  as  possible.  On  the  other  hand, 
unnecessarily  included  items  can  restrict 
the  subsequent  development  choices 
needlessly. 

Abbott  [Abbott86]  provides  a  non- 
exhaustive  list  of  C-requirements  is¬ 
sues: 

•  why  the  user  wants  the  system 

•  how  the  user  intends  to  use  the  sys¬ 
tem 

•  what  other  systems  and  procedures 
will  interface  with  the  planned  sys¬ 
tem 

•  what  expertise  the  people  have  who 
will  actually  operate  the  system 

•what  information  the  system  must 
be  able  to  handle 

•  whether  there  are  any  legal  con¬ 
straints  ( e.g .,  record  retention  re¬ 
quirements) 

•  whether  the  system  must  enforce 
any  integrity  constraints  (e.g.,  access 
limitations) 

•  what  data  processing  functions  the 
system  should  perform  for  the  user. 

Optional  issues  include: 

•  on  what  hardware  must  the  planned 
system  operate 

•  in  what  programming  language  must 
the  system  be  written 

•  on  what  operating  system  must  the 
system  be  installed 

•  what  expected  load  must  the  system 
be  able  to  handle  (e.g.,  in  trans¬ 
actions  per  hour) 

•  what  response  time  is  needed  from 
the  system 

•  what  enhancements  must  be  ex¬ 
pected  for  the  system  after  initial  use 

•what  design  qualities  are  expected 
of  the  system 

•  what  auditing  processes  must  be 
performed 

•what  physical  constraints  exist  for 
the  system  (e.g.,  need  for  air  con¬ 
ditioning  because  of  location) 

•  what  peripheral  devices  must  be 
used 

•  Attributes:  The  desirable  attributes  of 
C-requirements  cannot  be  characterized 
easily  without  knowing  the  life-cycle 
context  and  the  application  context. 
Each  of  the  attributes  in  section  III.2.b 
might  be  of  importance  under  certain 


circumstances.  However,  the  most  de¬ 
sirable  attributes  of  C-requirements  are 
completeness  (at  least  from  the 
customer’s  perspective),  consistency, 
and  clarity.  In  addition,  depending  on 
the  need  for  changes,  it  may  be  desir¬ 
able  for  the  product  to  be  structured, 
traceable,  and  formal. 

2.  D-Requirements 

The  purpose  of  D-requirements  is  to  answer  the 
question  what  functions,  from  a  developer's  point  of 
view,  must  a  software  system  fulfill?  This  section 
characterizes  products  of  type  D-requirements,  using 
the  characterization  scheme  introduced  in  section  III 
(partly  reflected  in  Figure  5).  Processes  of  type  D- 
requirements  are  treated  in  [Brackett90], 

a.  Purpose  and  context 

The  purpose  and  context  of  products  of  type  D- 
requirements  can  >'  characterized  as  follows: 

•  Product  Perspective:  For  our  purposes 
here,  we  generalize  across  all  possible 
application  domains  and  quality  require¬ 
ments. 

•  Process  Perspective:  For  our  purposes 
here,  we  generalize  across  all  possible 
life-cycle  models.  We  are  interested  in 
product  and  process  types  related  to 
overall  system  requirements  and  their 
validation. 

•  Use  Perspective:  D-requirements  de¬ 
fine,  for  the  software  developer,  the 
functional  and  non-functional  character¬ 
istics  the  product  under  development 
must  fulfill.  Therefore,  D-requirements 
serve  as  a  basis  for  communication  with 
the  developer.  In  addition,  they  serve  as 
input  product  for  the  subsequent  crea¬ 
tion  of  the  software  design,  as  reference 
document  for  the  integration  and  system 
testing  (V&V),  and  as  the  potential 
starting  point  for  maintenance  activities 
(especially  in  the  case  of  adaptive 
maintenance).  The  D-requirements 
product  is  evolved  from  the  C- 
requirements;  created  during  the  D- 
requirements  process;  used  during  de¬ 
sign,  verification  and  validation,  inte¬ 
gration,  and  maintenance  activities;  and 
updated  throughout  the  entire  lifetime 
of  the  corresponding  software  product. 

•  People  Perspective:  D-requirements 
are  used  by  sub-contractors,  specifica¬ 
tion  engineers,  designers,  verification 
and  validation  people,  quality  assurance 
personnel,  maintenance  personnel,  and 
managers. 
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b.  Content 

The  content  of  D-requirements  can  be  charac¬ 
terized  as  follows: 

•  Aspects:  D-requirements  address  the 
aspects  behavior ,  interface ,  and 
structure,  insofar  as  they  are  important 
to  the  developers.  Due  to  the  difference 
in  audience,  D-requirements  typically 
are  specified  in  a  different  format  from 
that  used  for  C-requirements.  Often 
more  formal  languages  are  used  (e.g., 
state-machine  languages)  than  for  C- 
requirements  (e.g.,  SADT). 

•  D-requirements,  too,  can  suffer  from 
over-specification,  as  well  as  under¬ 
specification.  Subsequent  development 
choices  should  not  needlessly  be 
restricted. 

•  Attributes:  The  desirable  attributes  of 
D-requirements  cannot  be  characterized 
easily  without  knowing  the  life-cycle 
and  the  application  contexts.  Each  of 
the  attributes  in  section  III.2.b  might  be 
of  importance  under  certain  cir¬ 
cumstances.  However,  the  most  desir¬ 
able  attributes  of  D-requirements  are 
completeness  (at  least  from  the 
developer’s  perspective),  consistency, 
formality,  traceability  (from  the  C- 
requirements,  to  the  design),  and  struc¬ 
turedness.  Traceability  from  the  C- 
requirements  specification  can  be  easily 
achieved  if  the  D-requirements  specifi¬ 
cation  evolves  from  the  C-requirements 
specification,  rather  than  being  a  com¬ 
pletely  new  product. 

3.  Design 

The  purpose  of  a  design  is  to  answer  the  question 
how  can  a  system  be  built  to  behave  as  described  in 
its  related  D-requirements?  This  section  charac¬ 
terizes  the  design  phase,  using  the  characterization 
scheme  introduced  in  section  III  (partly  reflected  in 
Figure  6).  Processes  of  type  design  are  treated  in 
[Budgen89J. 

a.  Purpose  and  context 

The  purpose  and  context  of  products  of  type  de¬ 
sign  can  be  characterized  as  follows: 

•  Product  Perspective:  For  our  purposes 
here,  we  generalize  across  all  possible 
application  domains  and  quality  require¬ 
ments. 

•  Process  Perspective:  For  our  purposes 
here,  we  generalize  across  all  possible 
life-cycle  models.  We  are  interested  in 
product  and  process  types  related  to 


overall  system  requirements  and  their 
validation. 

•  Use  Perspective:  Design  products 
serve  as  a  basis  for  communication  with 
the  subsystem  or  module  designer  or 
implementor.  In  addition,  they  serve  as 
input  product  for  the  subsequent  crea¬ 
tion  of  the  subsystem  or  module  design 
or  implerr  tation,  as  reference  docu¬ 
ment  for  the  module  or  subsystem  inte¬ 
gration  testing  (V&V),  and  as  the  poten¬ 
tial  starting  point  for  local  maintenance 
activities.  A  design  product  is  derived 
from  its  related  D-requirements  product; 
created  as  the  result  of  a  design  process; 
used  during  design,  implementation, 
verification  and  validation,  integration, 
and  maintenance  activities;  and  modi¬ 
fied  throughout  the  entire  lifetime  of  the 
corresponding  software  system. 

•  People  Perspective:  Designs  are  used 
by  designers,  implementors,  verification 
and  validation  people,  quaiity  assurance 
personnel,  maintenance  personnel,  and 
managers.  They  define  the  overall 
structure  of  the  software  system  to  be 
built.  They  define  subsystems  or  mod¬ 
ules,  their  functional  requirements,  and 
interfaces  between  them.  The  function¬ 
al  requirements  serve  as  the  input  for 
the  subsystem/module  design  activities, 
as  do  the  D-requirements  for  the  overall 
system  design  phase. 

b.  Content 

The  content  of  a  design  product  can  be  charac¬ 
terized  as  follows: 

•  Aspects:  Designs  address  the  aspects 
flow  and  structure,  insofar  as  they  are 
important  for  further  development. 
Which  specific  software  aspects  need  to 
be  specified  predominantly  depends  on 
the  project  and  application  type.  In  the 
case  of  information  systems,  the  data 
structure  might  be  dominant;  for  em¬ 
bedded  systems,  control  flow,  inter¬ 
faces,  and  synchronization  might  be 
dominant.  Practical  constraints  during 
design  may  include  (1)  the  considera¬ 
tion  of  ties  between  the  software  system 
under  development  and  its  anticipated 
target  environment  and  (2)  the  aware¬ 
ness  of  compatibility  with  the  chosen 
implementation  language  and  hardware. 

•  Attributes:  The  desirable  attributes  of 
designs  cannot  be  characterized  easily 
without  knowing  the  life-cycle  and  ap¬ 
plication  context.  Each  of  the  attributes 
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in  section  III.2.b  may  be  of  importance 
under  certain  circumstances.  However, 
the  most  desirable  attributes  of  designs 
are  completeness  (at  least  from  the 
implementor’s  perspective),  consisten¬ 
cy,  formality,  traceability  (from  the  D- 
requirements,  to  lower-level  designs  or 
code),  clarity,  and  structuredness. 

4.  Other  Object  Types 

There  are  many  other  software  objects  for  which 
sound  specifications  are  needed.  Examples  are: 

•  management  processes  (e.g.,  monitoring 
schedule  adherence) 

•  management  products  (e.g.,  schedules) 

•  other  life-cycle  processes  (e.g.,  testing) 

•  analysis  processes  (e.g.,  measurement) 

It  is  important  to  understand  all  aspects  of  the  soft¬ 
ware  life-cycle.  The  first  step  to  better  understand¬ 
ing  is  the  ability  to  specify  all  aspects.  The  more 
formally  a  process  or  product  type  can  be  specified, 
the  better  it  can  be  communicated,  taught,  executed, 
and  improved.  Broadening  our  view  of  life-cycle 
objects  that  need  to  be  specified  from  just  the  con¬ 
ventional  products  (including  documents)  to  all 
types  of  products  and  processes  involved  in  software 
evolution  is  the  objective  of  this  section. 

Individual  software  development  organizations  es¬ 
tablish  their  own  specification  standards.  Most  of 
these  standards  are  not  well  documented.  The  two 
major  sources  of  standards  are  the  Department  of 
Defense  and  ANSI/IEEE.  Examples  of  standards 
from  those  sources  are: 

•  DoD  Std  2167A  on  “Software 
Development”  [DoD88a] 

•  DoD  Std  2168  on  “Software  Quality 
Assurance”  [DoD88b] 

•  ANSI/IEEE  Std  830  on  “Software  Re¬ 
quirements  Specification”  [IEEE84] 

V.  Guidelines  for  Selecting  and  Evaluating 
Specification  Techniques 

One  important  application  of  the  characterization 
scheme  of  section  III  is  its  use  in  selecting  and  evalu¬ 
ating  specification  techniques.  Although  this  is  an  im¬ 
portant  topic,  we  can  deal  with  it  only  briefly  here. 

1.  Selection  of  Proper  Specification  Techniques 

For  selecting  an  appropriate  specification  technique, 
the  framework  should  be  applied  as  follows: 

a.  Define  specification  requirements 

•  Explicitly  define  purpose/context  (III.  1) 
and  aspects  (III.2.a)  of  the  specification 
type  of  interest  by  using  the  matrix 


depicted  in  Figure  3a.  The  selection  of 
methods  and  tools  only  makes  sense  in 
the  context  of  a  specific  project  or  proj¬ 
ect  type. 

•  Derive,  for  each  specification  aspect  of 
interest,  the  appropriate  attributes 
(II.2.b),  using  the  matrix  depicted  in 
Figure  3b. 

b.  Chose  specification  techniques 

•  Select  models  and  languages  (III.3)  that 
best  match  the  derived  aspect-attribute 
matrix.  Obviously,  this  selection  would 
be  most  efficient  if  we  had  definiuons 
of  a  number  of  candidate  models  and 
languages  in  the  form  of  the  matrix  in 
Figure  3b. 

•  Select  methods  (H.5.a)  and  tools  (Il.S.b) 
that  best  support  use  of  the  selected 
models  and  languages. 

2.  Evaluation  of  Specification  Techniques 

The  evaluation  of  techniques  needs  to  be  done  with 
respect  to  some  goal  [Basili88],  The  characterization 
of  a  technique  according  to  our  framework  has  two 
advantages  in  this  context:  (1)  it  provides  valuable 
input  as  to  what  evaluation  goals  might  be  of  interest 
(e.g.,  quality  requirements  [III. l.a.ii]),  and  (2)  it  pro¬ 
vides  a  basis  for  relating  negative  or  unsatisfactory 
observations  regarding  the  effects  of  a  technique  to 
particular  characteristics  or  to  actual  use  of  the  tech¬ 
nique  (e.g.,  a  C-requirement  technique  may  be  in¬ 
effective  because  it  is  too  formal  for  the  customer  to 
understand). 

We  can  think  of  two  kinds  of  evaluations:  (1)  evalu¬ 
ating  whether  a  chosen  technique  actually  possesses 
the  characteristics  promised  by  its  creator  or  ex¬ 
pected  by  us  or  (2)  evaluating  whether  a  chosen 
technique  achieves  the  expected  impact  on  software 
quality  or  productivity. 

The  first  type  of  evaluation  is  relatively  easy.  The 
evaluation  goal  is  implicitly  defined  by  the  original 
characterization  of  the  technique  on  which  its  selec¬ 
tion  was  based  (see  IV.  1).  We  can  develop  a  second 
characterization  during  the  use  of  the  technique  in  a 
real  project,  reflecting  our  actual  experience.  This 
actual  characterization  can  then  be  compared  with 
the  original  characterization. 

The  second  type  of  evaluation  requires  more  plan¬ 
ning.  Evaluation  goals  should  identify  the  perspec¬ 
tive  (i.e.,  the  audience  for  this  evaluation),  which 
can  be  derived  from  the  people  dimension  of  our 
framework,  as  well  as  a  characterization  of  the  envi¬ 
ronment  (the  life-cycle  model  that  was  used  and  the 
application  type),  which  can  be  derived  from  the 
process  and  application  context  dimensions  of  our 
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framework.  Perhaps  the  hardest  part  of  the  evalu¬ 
ation  process  for  specification  techniques  is  for¬ 
mulating  recommendations  about  what  should  be 
improved:  train  people  better,  choose  better  tech¬ 
niques,  make  sure  that  techniques  are  more 
thoroughly  applied,  or  apply  different  life-cycle 
models  or  management  structure.  Defining  expec¬ 
tations  for  the  use  of  a  technique  based  upon  our 
framework  and  selecting  it  according  to  the  proce¬ 
dure  presented  in  section  IV. 1.  allows  comparison  of 
expectation  to  reality,  thus  providing  a  more  objec¬ 
tive  basis  on  which  to  improve  existing  techniques 
or  select  better-suited  ones  than  is  otherwise  avail¬ 
able. 

It  is  important  to  recognize  that  evaluation,  although 
potentially  time-consuming  and  expensive,  is  neces¬ 
sary  to  guarantee  improvement  in  the  way  we  select 
and  use  specification  techniques. 

VI.  Assessment  of  Current  Maturity  and  Future 
Directions 

Many  people  have  a  limited  view  of  what  software 
life-cycle  objects  are  subject  to  specification  and  how 
they  should  be  specified.  Commonly  held  beliefs  in¬ 
clude: 

•  Only  product  types,  not  process  types,  need 
be  specified. 

•  Product  types  in  later  phases  of  the  life  cycle 
should  be  specified  more  formally. 

•  Specifications  are  mostly  used  for  purposes 
of  communication  and  validation. 

These  attitudes  provide  fertile  ground  for  change.  Fu¬ 
ture  developments  are  likely  to  include: 

•  The  broadening  of  the  notion  of  specification 
to  all  product  and  process  types  in  the  context 
of  software  evolution. 

•  The  development  of  specific  process  specifi¬ 
cation  languages. 

•  The  introduction  of  greater  formality  of  spec¬ 
ification. 

•  The  generation  of  custom-tailored  environ¬ 
ment  components  {e.g.,  database  schemes) 
from  specifications  of  the  software  processes 
to  be  supported. 

This  prediction  is  motivated  by  the  many  needs  of  the 
software  community,  all  ultimately  aimed  at  improving 
productivity  and  quality  ot  software  evolution  and  its 
resulting  products: 

•  Better  understanding  of  the  software  evolu¬ 
tion  process  itself. 

•  Better  control  of  process  executions. 

•  Better  traceability  and  predictability  of  the 
impact  of  decisions  made  early  in  the  project. 

•  Better  basis  for  reuse. 


•  Better  basis  for  constructing  automated  envi¬ 
ronments  that  actually  support  some 
predefined  set  of  processes. 

•  A  basis  for  employing  generator  technology 
for  building  environment  components  from 
process  specifications. 


Glossary 


The  following  terminology  is  used  throughout  the 
module,  except  in  the  abstracts  found  in  the  bibliog¬ 
raphy. 

process 

Each  activity  or  action  that  consumes  (or  is  in¬ 
tended  to  consume)  input  products  and/or  pro¬ 
duces  (or  is  intended  to  produce)  output  prod¬ 
ucts,  e.g.,  the  overall  software  life  cycle,  each 
life-cycle  activity  (such  as  designing  or  testing), 
or  even  each  action  of  the  compilation  process. 
Process  is  used  in  a  very  general  sense. 

process  type 

A  class  of  processes  with  common  characteris¬ 
tics.  For  example,  all  development  processes 
executed  according  to  some  standard  X  are  said 
to  be  of  type  X. 

product 

Each  document  or  artifact  created  during  (or  for) 
a  project  is  a  product,  independent  of  whether  or 
not  it  is  designated  for  delivery  to  the  customer 
{e.g.,  design  document,  code,  measurement  data, 
project  plan).  This  is  a  broader  definition  than 
that  of  the  IEEE  (“[a]  software  entity  designated 
for  delivery  to  a  user”)  [IEEE83], 

product  type 

A  class  of  products  with  common  characteris¬ 
tics.  For  example,  all  requirements  products  cre¬ 
ated  according  to  some  standard  X  are  said  to  be 
of  type  X. 

project  execution  stage 

The  project  activities  concerned  with  performing 
the  project  according  to  the  plans  (specifica¬ 
tions)  produced  in  the  preceding  planning  stage. 
(See  software  project  model.) 

project  feedback  stage 

The  project  activities  concerned  with  monitoring 
the  effectiveness  of  the  specifications  used  dur- 
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ing  the  execution  stage,  evaluating  those  results 
after  execution,  and  feeding  them  into  the  plan¬ 
ning  stages  of  future  projects.  (See  software 
project  model.) 

project  planning  stage 

The  project  activities  preceding  the  actual  ex¬ 
ecution  stage  of  a  project.  This  stage  is  con¬ 
cerned  with  creating  specifications  of  all 
relevant  product  and  process  types.  This  in¬ 
cludes  all  products,  whether  deliverables  or  not, 
and  processes  for  management,  construction, 
control,  and  analysis.  (See  software  project 
model.) 

requirement 

Any  function,  constraint,  or  other  property  that 
must  be  provided,  met,  or  satisfied  to  fill  the 
needs  of  the  system’s  intended  uscr(s) 
[Abbott86], 

software  development 

The  process  of  translating  customcr/user  needs 
into  a  system  for  operational  use  [IEEE83], 

software  evolution 

The  process  of  software  development  and  main¬ 
tenance. 

software  maintenance 

The  process  of  modifying  a  product  after 
delivery  to  correct  faults  ( corrective  mainte¬ 
nance ),  to  improve  performance  or  other  attri¬ 
butes  (perfective  maintenance ),  or  to  adapt  the 
product  to  a  changed  environment  ( adaptive 
maintenance). 

software  project  model 

The  software  project  model  underlying  this  cur¬ 
riculum  module  is  based  on  (1)  planning,  (2)  ex¬ 
ecution,  and  (3)  evaluation-based  feedback 
stages.  Conventional  life-cycle  models  describe 
the  execution  part.  Specifications  are  created 
during  planning,  used  to  control  the  performance 
of  processes  and  the  creation  of  products  during 
execution,  and  evaluated  after  execution  during 
the  feedback  stage. 

specification 

A  plan  or  standard  that  provides  a 
description/characterization  of  a  software  prod¬ 
uct  or  process  type.  A  specification  is  itself  a 
product  resulting  from  the  planning  process.  A 
process  specification  describes  how  processes  of 


some  type  should  be  performed;  a  product  speci¬ 
fication  describes  how  products  of  some  type 
should  look.  Having  process  and  product  speci¬ 
fications  available  allows  us  to  instantiate  indi¬ 
vidual  processes  and  products  from  such  specifi¬ 
cations  during  project  execution.  It  should  be 
clear  that  the  term  specification  refers  to  the  de¬ 
scription  of  a  product  or  process  type,  not  to  the 
individual  product  or  process. 

Among  its  definitions  for  specification , 
[Webster87]  gives: 

1.  The  act  or  process  of  specifying. 

2.  A  detailed  precise  presentation  or 
something  or  of  a  plan  or  proposal 
for  something  ...  a  statement  of  legal 
particulars  (as  of  charges  or  of  con¬ 
tract  terms). 

According  to  [1EEE83],  specification  in  the  con¬ 
text  of  software  engineering  is: 

1. A  document  that  prescribes,  in  a 
complete,  precise,  verifiable  manner, 
the  requirements,  design,  behavior, 
or  other  characteristics  of  a  system 
or  system  component. 

2.  The  process  of  developing  a  specifi¬ 
cation. 
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Figure  1.  Reference  life-cycle  model  and  terminology. 
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Figure  3a.  Purpose  &  Context  vs.  Content  (Aspect). 
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Figure  3b.  Content  (Attributes)  vs.  Content  (Aspects). 
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Figure  5.  D-Requirements  Characterization. 
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Figure  6.  Design  Characterization. 
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_ Software  Specifications:  A  Framework 

Teaching  Considerations 


Uses  of  this  Material _ 

The  material  presented  in  this  module  is  intended  to 
be  used  in  one  of  three  ways: 

1.  As  background  material  for  teachers  pre¬ 
paring  software  engineering  courses. 

2.  As  the  basis  of  an  introductory  unit  on 
requirements  (C-  or  D-requirements)  or 
design. 

3.  As  the  basis  of  a  stand-alone  course  on 
the  selection  and  assessment  of  software 
engineering  methods  and  tools. 


Suggested  Introductory  Literature 

The  following  nine  books  and  papers  arc  recom¬ 
mended  as  introductory  literature  on  the  topics  dealt 
with  in  this  module: 

Abbott86  Gomaa86  Lamb88 

DeMarco79  Hayes87  Rzepka85 

Gehani86  Jensen79  Sommerville89 


Suggested  Course  Schedule _ 

The  author  has  taught  the  material  in  this  module  as 
a  graduate  course  called  “Assessment  of  Software 
Requirements  Methods  and  Tools”  at  the  University 
of  Maryland.  This  course  is  a  stand-alone  course  on 
selection  and  assessment,  as  suggested  above.  The 
planned  schedule  for  this  course  (14  weeks,  2  hours 
per  week)  is  shown  below.  References  to  the  mod¬ 
ule  outline  are  shown  in  parentheses. 

Week  1  Overview  of  software  evolution 
(processes,  products,  etc.). 

Week  2  Overview  of  life-cycle  models 
and  the  roles  played  by  specifi¬ 
cations  in  these  models. 

Weeks  3-5  Detailed  presentation  and  dis¬ 
cussion  of  the  characterization 
scheme  (III). 


Week  6  Presentation  and  discussion  of 
selection  and  evaluation  criteria 
for  specifications  (V). 

Exercise:  An  informal  software 
specification  is  given  to  four 
student  teams,  who  are  asked  to 
develop  corresponding  D- 
requirements  documents  using 
any  of  the  following  ap¬ 
proaches:  SADT,  Petri  nets,  R 
nets,  NRL  approach,  algebraic 
approach,  or  axiomatic  ap¬ 
proach.  The  teams  are  asked  to 
justify  their  choice  and  to  deter¬ 
mine  the  degree  to  which  the 
method  used  fulfill  theii  expec¬ 
tations. 

Week  7  Presentation  and  discussion  of 
C-/D-requirements  specification 
(IV.  1-2). 

Week  8  Presentation  and  discussion  of 
formal  approaches  to  specifying 
D-requirements. 

Week  9  Other  specification  types 

(IV.3-4). 

Week  10  Presentation  and  discussion  of 

exercise  by  team  1 . 

Week  11  Presentation  and  discussion  of 

exercise  by  team  2. 

Week  12  Presentation  and  discussion  of 

exercise  by  team  3. 

Week  13  Presentation  and  discussion  of 

exercise  by  team  4. 

Week  14  Course  wrap-up. 

The  requirements  document  used  in  the  class  ex¬ 
ercise  describes  a  heating  control  system.  It  is  one 
of  four  informal  sets  of  requirements  that  have  been 
used  as  examples  within  the  specification  commu¬ 
nity  [1WSSD87], 
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Exercises 


Depending  on  individual  course  objectives,  the  fol¬ 
lowing  student  exercises  may  be  useful: 

1.  Distribute  an  informal  requirements  doc¬ 
ument  and  ask  students  to  create  a  more 
formal  D-requirements  document.  (See 
course  description  above.)  Students  can 
be  required  either  to  use  a  particular 
method  or  to  chose  one  themselves  from 
a  candidate  set  of  available  methods  and 
tools.  Students  should  then  assess  the  ef¬ 
fectiveness  of  the  method  used. 

2.  Provide  a  concrete  project  scenario  (use 
the  characterization  scheme  in  III.  1-2) 
and  ask  students  to  chose  and  justify 
their  choice  of  the  most  appropriate  spec¬ 
ification  methods(s)  and/or  tool(s) 
(III.3-4). 

3.  Provide  students  with  corresponding  D- 
requirements,  design,  and  code  products. 

Have  them  perform  modification  and/or 
verification  on  these  products  and  assess 
which  of  the  product  characteristics  are 
helpful  and  which  cause  difficulties  in 
performing  the  tasks. 
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partment  of  Defense,  Washington,  D.C.,  29  April 
1988. 
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Flrth87 

Firth,  R.,  et  al.  A  Classification  Scheme  for  Software 
Development  Methods.  Technical  Report  CMU/SEI- 
87-TR-41,  Software  Engineering  Institute,  Carnegie 
Mellon  University,  Pittsburgh,  Pa.,  June  1987. 

Abstract:  Software  development  methods  are  used 
to  assist  with  the  process  of  designing  software  for 
real-time  systems.  Many  such  methods  have  come 
into  practice  over  the  last  decade,  and  new  methods 
are  emerging.  These  new  methods  are  more  power¬ 
ful  than  the  old  ones,  especially  with  regard  to  real¬ 
time  aspects  of  the  software.  This  report  describes 
a  classification  scheme  for  software  development 
methods,  includes  descriptions  of  the  major  charac¬ 
teristics  of  such  methods,  and  contains  some  more 
words  of  advice  on  choosing  and  applying  such 
methods. 

Gehani86 

Gehani,  N.,  and  A.  D.  McGettrick,  eds.  Software 
Specification  Techniques.  Reading,  Mass.: 
Addison-Wesley,  1986. 

A  collection  of  papers  on  formal  specification  tech¬ 
niques.  This  book  addresses  general  principles,  par¬ 
ticular  specification  techniques,  case  studies  of  ac¬ 
tual  experiences,  and  systems  for  automatic  gener¬ 
ation  of  prototypes  from  specifications. 

Goldsack85 

Goldsack,  S.  J.  Ada  for  Specification:  Possibilities 
and  Limitations.  Cambridge,  England:  Cambridge 
University  Press,  1985. 

Gomaa86 

Gomaa,  H.  “Software  Development  of  Real-Time 
Systems."  Comm.  ACM  29, 1  (July  1986),  657-668. 

Suitable  for  use  by  both  instructors  and  students  as 
an  easily  readable  introduction  to  issues  of  real-time 
products. 

Guttag78 

Guttag,  J.  V.,  E.  Horowitz,  and  D.  R.  Musser. 
“Abstract  Data  Types  and  Software  Validation.” 
Comm.  ACM  21,  12  (Dec.  1978),  1048-1064. 

Abstract:  A  data  abstraction  can  be  naturally  spec¬ 
ified  using  algebraic  axioms.  The  virtue  of  these 
axioms  is  that  they  permit  a  representation- 
independent  formal  specification  of  a  data  type.  An 
example  is  given  which  shows  how  to  employ  al¬ 
gebraic  axioms  at  successive  levels  of  implemen¬ 
tation.  The  major  thrust  of  the  paper  is  twofold. 
First,  it  is  shown  how  the  use  of  algebraic 
axiomatizations  can  simplify  the  process  of  proving 
the  correctness  of  an  implementation  of  an  abstract 
data  type.  Second,  semi-automatic  tools  are  de¬ 


scribed  which  can  be  used  both  to  automate  such 
proofs  of  correctness  and  to  derive  an  immediate 
implementation  from  the  axioms.  This  implemen¬ 
tation  allows  for  limited  testing  of  programs  at  de¬ 
sign  time,  before  a  conventional  implementation  is 
accomplished. 

Hare!88a 

Harel,  D.  “On  Visual  Formalisms.”  Comm.  ACM  31, 
5  (May  1988),  514-530. 

An  elegant  and  clearly-written  paper  that  discusses 
a  number  of  important  issues  about  model  represen¬ 
tation.  While  the  first  part  of  the  paper  is  concerned 
with  general  issues,  the  latter  part  provides  an  inter¬ 
esting  exposition  of  statecharts,  and  includes  a  de¬ 
tailed  example  in  the  form  of  a  description  of  a 
digital  watch.  The  paper  will  be  of  particular  inter¬ 
est  to  instructors  concerned  with  the  imprecision  of 
the  graphical  notations  frequently  used  to  describe 
software  requirements. 

Harel88b 

Harel,  D.,  et  al.  “STATEMATE:  A  Working  Envi¬ 
ronment  for  the  Development  of  Complex  Reactive 
Systems.”  Proc.  10th  Inti.  Conf.  Software  Eng. 
Washington,  D.C.:  IEEE  Computer  Society  Press, 
1988,  396-406. 

Abstract:  This  paper  provides  a  brief  overview  of 
the  STATEMATE  system,  constructed  over  the  past 
three  years  by  i-Logix  Inc.,  and  Ad  Cad  Ltd. 
STATEMATE  is  a  graphical  working  environment, 
intended  for  the  specification,  analysis,  design  and 
documentation  of  large  and  complex  reactive  sys¬ 
tems,  such  as  real-time  embedded  systems,  control 
and  communication  systems,  and  interactive  soft¬ 
ware.  It  enables  a  user  to  prepare,  analyze  and 
debug  diagrammatic,  yet  precise,  descriptions  of  the 
system  under  development  from  three  inter-related 
points  of  view,  capturing  structure,  functionality 
and  behavior.  These  views  are  represented  by  three 
graphical  languages,  the  most  intricate  of  which  is 
the  language  of  statecharts  used  to  depict  reactive 
behavior  over  time.  In  addition  to  the  use  of 
statecharts,  the  main  novelty  of  STATEMATE  is  in 
the  fact  that  it  'understands'  the  entire  descriptions 
perfectly,  to  the  point  of  being  able  to  analyze  them 
for  crucial  dynamic  properties,  to  carry  out  rigor¬ 
ous  animated  executions  and  simulations  of  the  de¬ 
scribed  system,  and  to  create  runing  code  automat¬ 
ically.  These  features  are  invaluable  when  it  comes 
to  the  quality  and  reliability  of  the  final  outcome. 

Hatiey87 

Hatley,  D.  J.,  and  I.  A.  Pirbhai.  Strategies  for  Real- 
Time  System  Specification.  New  York:  Dorset 
House,  1987. 
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This  is  a  well-written  text  on  Real-Time  Structured 
Analysis.  This  book  should  be  read  in  conjunction 
with  [Ward89]  in  order  better  to  understand  the  ca¬ 
pabilities  of  the  notation.  This  text  and  [Ward85] 
are  alternative  texts;  the  choice  of  a  text  for  teach¬ 
ing  Real-Time  Structured  Analysis  may  depend 
upon  whether  the  computer  tools  to  be  used  support 
only  the  Hatley  notation  or  only  the  Ward  notation. 

Hayes87 

Hayes,  Ian,  ed.  Specification  Case  Studies.  Engle¬ 
wood  Giffs,  N.J.;  Prentice/Hall  International,  1987. 

A  collected  set  of  case  studies  based  on  the  use  of 
Z,  providing  a  well-structured  introduction  to  the 
use  of  formal  methods.  The  section  on  specification 
of  the  UNIX  filing  system  may  involve  sufficiently 
familiar  material  to  provide  a  good  introduction  for 
many  students. 

Suitable  for  use  by  both  instructors  and  students. 

Heninger80 

Heningcr,  K.  L.  “Specifying  Software  Requirements 
for  Complex  Systems;  New  Techniques  and  Their 
Applications.”  IEEE  Trans.  Software  Eng.  SE-6 ,  1 
(January  1980),  2-13. 

Abstract:  This  paper  concerns  new  techniques  for 
making  requirements  specifications  precise,  con¬ 
cise.  unambiguous,  and  easy  to  check  for  complete¬ 
ness  and  consistency.  The  techniques  are  well- 
suited  for  complex  real-time  software  systems;  they 
were  developed  to  document  the  requirements  of  ex¬ 
isting  flight  software  for  the  Navy's  A-7  aircraft. 
The  paper  outlines  the  information  that  belongs  in  a 
requirements  document  and  discusses  the  objectives 
behind  the  techniques.  Each  technique  is  described 
and  illustrated  with  examples  from  the  A-7  docu¬ 
ment.  The  purpose  of  the  paper  is  to  introduce  the 
A-7  document  as  a  model  of  a  disciplined  approach 
to  requirements  specification;  the  document  is 
available  to  anyone  who  wishes  to  see  a  fully 
worked  out  example  of  the  approach. 

Henry81 

Henry,  S.,  and  D.  Kafura.  “Software  Structure 
Metrics  Based  on  Information  Row.”  IEEE  Trans. 
Software  Eng.  SE-7,  5  (Sept.  1981),  510-518. 

Abstract:  Structured  design  methodologies  provide 
a  disciplined  and  organized  guide  to  the  construc¬ 
tion  of  software  systems.  However,  while  the  meth¬ 
odology  structures  and  documents  the  points  at 
which  design  decisions  are  made,  it  does  not  pro¬ 
vide  a  specific,  quantitative  basis  for  making  these 
decisions.  Typically,  the  designers'  only  guidelines 
are  qualitative,  perhaps  even  vague,  principles  such 
as  "functionality,"  "data  transparency,"  or 
"clarity."  This  paper,  like  several  recent  publica¬ 


tions,  defines  and  validates  a  set  of  software  metrics 
which  are  appropriate  for  evaluating  the  structure 
of  large-scale  systems.  These  metrics  are  based  on 
the  measurement  of  information  flow  between  sys 
tem  components.  Specific  metrics  are  defined  for 
procedure  complexity,  module  complexity,  and 
module  coupling.  The  validation,  using  the  source 
code  for  the  UNIX  opeiating  system,  shows  that  the 
complexity  measures  are  strongly  correlated  with 
the  occurrence  of  changes.  Further,  the  metrics  for 
procedures  and  modules  can  be  interpreted  to 
reveal  various  types  of  structural  flaws  in  the  design 
and  implementation. 

Hoare69 

Hoare,  C.  A.  R.  “An  Axiomatic  Basis  for  Computer 
Programming.”  Comm  ACM  12,  10  (Oct.  1969), 
576-580. 

Abstract:  In  this  paper  an  attempt  is  made  to  ex¬ 
plore  the  logical  foundation  of  computer  program¬ 
ming  by  use  of  techniques  which  were  first  applied 
in  the  study  of  geometrv  and  have  later  been  ex¬ 
tended  to  other  branches  of  mathematics.  This  in¬ 
volves  the  elucidation  of  sets  of  axioms  and  rules  of 
inference  which  can  be  used  in  proofs  of  the 
properties  of  computer  programs.  Examples  are 
given  of  such  axioms  and  rules,  and  a  formal  proof 
of  a  simple  theorem  is  displayed.  Finally,  it  is 
argued  that  important  advantages,  both  theoretical 
and  practical,  may  follow  from  a  pursuance  of  these 
topics. 

IEEE83 

IEEE.  IEEE  Standard  Glossar'j  of  Software  Engi¬ 
neering  Terminology.  New  York;  IEEE,  1983. 
ANSI/IEEE  Std  729-1983. 

Provides  definitions  for  many  of  the  terms  used  in 
software  engineering. 

IEEE84 

IEEE.  IEEE  Guide  to  Software  Requirements 
Specifications.  New  York;  IEEE.  1984.  ANSI/ 
IEEE  Std  830-1984. 

IWSSD82 

First  Inti.  Workshop  on  Software  Specification  and 
Design.  Washington,  D.C.:  IEEE  Computer  Soci¬ 
ety  Press,  1982. 

IWSSD84 

2nd  Inti  Workshop  on  Software  Specification  and 
Design.  Washington,  D.C.:  IEEE  Computer  Soci¬ 
ety  Press,  1984. 
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IWSSD85 

3rd  Inti.  Workshop  on  Software  Specification  and 
Design.  Washington,  D.C.:  IEEE  Computer  Soci¬ 
ety  Press,  1985. 

IWSSD87 

4  th  Inti.  Workshop  on  Software  Specification  and 
Design.  Washington,  D.C.:  IEEE  Computer  Soci¬ 
ety  Press.  1987.  Also  appears  as  ACM  Software  En¬ 
gineering  Notes  14,  3  (May  1989). 

Jensen79 

Jensen,  R.  W.,  and  C.  C.  Tonies.  Software 
Engineering.  EngleWood  Cliffs,  N.J.:  Prentice-Hall, 
1979. 

A  collection  of  primarily  management-orientej  arti¬ 
cles.  Structured  program  design  is  covered. 

Lamb88 

Lamb,  David  Alex.  Software  Engineering:  Planning 
for  Change.  Englewood  Cliffs,  N.J.:  Prentice-Hall, 
1988. 

This  book  introduces  basic  software  engineering 
concepts.  Among  other  topics,  it  contains  an 
elaborate  discussion  of  “specification  and 
verification.”  Specific  emphasis  is  placed  on  al¬ 
gebraic  specifications,  trace  specifications,  and  ab¬ 
stract  modeling. 

Levlne89 

Levine,  Linda,  Linda  H.  Pesante,  and  Susan 
B.  Dunkle.  Technical  Writing  for  Software 
Engineers.  Curriculum  Module  SEI-CM-23-1.0, 
Software  Engineering  Institute,  Carnegie  Mellon 
University,  Pittsburgh,  Pa.,  Dec.  1989. 

Capsule  Description:  This  module,  which  is  di¬ 
rected  specifically  to  software  engineers,  discusses 
the  writing  process  in  the  context  of  software  engi¬ 
neering.  Its  focus  is  on  the  basic  problem-solving 
activities  that  underlie  effective  writing,  many  of 
which  are  similar  to  those  underlying  software  de¬ 
velopment.  The  module  draws  on  related  work  in  a 
number  of  disciplines,  including  rhetorical  theory, 
discourse  analysis,  linguistics,  and  document  de¬ 
sign.  It  suggests  techniques  for  becoming  an  effec¬ 
tive  writer  and  offers  criteria  for  evaluating  writing. 

MIIIS86 

Mills,  H.  D.,  C.  Linger,  and  A.  R.  Hevner. 
Principles  of  Information  Systems  Analysis  and 
Design.  Orlando,  Fla.:  Academic  Press.  3986. 

This  book  describes  an  approach  to  requirements 
definition  for  information  systems  that  emphasizes 
the  use  of  models  showing  external  system  be¬ 


havior.  Black-box  and  state-machine  models  are 
used,  which  are  similar  in  concept  to  the  form  of 
representation  described  in  [HeningerSO], 

Parnas72 

Pamas,  D.  L.  “On  the  Criteria  to  be  used  in  decom¬ 
posing  systems  into  modules.”  Comm.  ACM  15,  12 
(Dec.  1972),  1053-1058. 

Abstract :  This  paper  discusses  modularization  as  a 
mechanism  for  improving  the  flexibility  and  com¬ 
prehensibility  of  a  system  while  allowing  the  shor¬ 
tening  of  its  development  time.  The  effectiveness  of 
a  “ modularization "  is  dependent  upon  the  criteria 
used  in  dividing  the  system  into  modules.  A  system 
design  problem  is  presented  and  both  a  convention¬ 
al  and  unconventional  decomposition  are  described. 

It  is  shown  that  the  unconventional  decompositions 
have  distinct  advantages  for  the  goals  outlined.  The 
criteria  used  in  arriving  at  the  decompositions  are 
discussed.  The  unconventional  decomposition,  if 
implemented  with  the  conventional  assumption  that 
a  module  consists  of  one  or  more  subroutines,  will 
be  less  efficient  in  most  cases.  An  alternative  ap¬ 
proach  to  implementation  which  does  not  have  this 
effect  is  sketched. 

A  truly  “classical"  paper,  in  the  sense  of  being  often 
cited  but  probably  rarely  read.  It  is  a  very  important 
paper  that  lays  down  the  basic  ideas  about  infor¬ 
mation  hiding  but  in  a  very  concise  and  compact 
form.  The  discussion  is  based  upon  an  example  of  a 
problem  that  may  not  be  very  familiar  to  many 
readers. 

The  teacher  must  read  this  paper;  the  student  might 
do  better  to  settle  for  the  teacher’s  interpretation. 

Peterson77 

Peterson,  J.  “Petri  Nets.”  ACM  Computing  Surveys 
9,3  (Sept.  1977),223-252. 

This  is  the  First  widely  circulated  survey  and  tutorial 
on  Petri  nets.  It  touches  briefly  on  modeling  with 
Petri  nets,  basic  definitions,  analysis  problems  and 
techniques,  Petri  net  languages,  and  related  models 
of  computation.  A  good  introduction  that  should  be 
readable  by  any  graduate  student. 

Peterson81 

Peterson,  J.  L.  Petri  Net  Theory  and  the  Modeling  of 
Systems.  Englewood  Cliffs,  N.J.:  Prentice-Hall, 
1981. 

This  books  makes  two  important  contributions:  it 
identifies  a  new  class  (called  Petri  net  languages)  in 
the  Chomsky  hierarchy,  and  it  organizes  a  set  of 
models  of  parallel  computation  into  a  lattice  in 
which  the  ordering  is  based  on  the  expressive  power 
of  a  model.  Examples  are  given  to  show  the  proper 
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inclusion  among  each  adjacent  pair  of  models  in  the 
lattice.  An  excellent  bibliography  is  provided. 

ROSS77 

Ross,  D.  T.,  and  K.  E.  Schoman,  Jr.  '‘Structured 
Analysis  for  Requirements  Definition.”  IEEE  Trans. 
Software  Eng.  SE-3 ,  1  (Jan.  1977),  6-15. 

Abstract:  Requirements  definition  encompasses  all 
aspects  of  system  development  prior  to  actual  sys¬ 
tem  design.  We  see  the  lack  of  an  adequate  ap¬ 
proach  to  requirements  definition  as  the  source  of 
major  dijficulties  in  current  systems  work.  This 
paper  examines  the  needs  for  requirements  defini¬ 
tion,  and  proposes  meeting  those  objectives  with 
three  interrelated  subjects:  context  analysis,  func¬ 
tional  specification,  and  design  constraints.  Re¬ 
quirements  definition  replaces  the  widely  used,  but 
never  well-defined,  term  "requirements  analysis." 

The  purpose  of  this  paper  is  to  present,  in  a  com¬ 
prehensive  manner,  concepts  that  apply  throughout 
requirements  definition  (and,  by  implication,  to  all 
of  system  development).  The  paper  discusses  ihe 
functional  architecture  of  systems,  the  characteris¬ 
tics  of  good  requirements  documentation,  the  per¬ 
sonnel  involved  in  the  process  of  analysis,  and  man¬ 
agement  guidelines  that  are  effective  even  in  com¬ 
plex  environments. 

The  paper  then  outlines  a  systematic  methodology 
that  incorporates,  in  both  notation  and  technique, 
the  concepts  previously  introduced.  Reference  is 
made  to  actual  requirements  definition  experience 
and  to  practicable  automated  support  tools  that 
may  be  used  with  the  methodology. 

Royce70 

Royce,  W.  W.  “Managing  the  Development  of  Large 
Software  Systems:  Concepts  and  Techniques.” 
WESCON  Technical  Papers  Volume  14,  Western 
Electronic  Show  and  Convention.  Los  Angeles: 
WESCON,  1970,  1-9.  Reprinted  in  Proc.  9th  Inti 
Conf.  Software  Eng.,  Washington,  D.C.:  IEEE 
Computer  Society  Press,  1987,  328-338. 

Abstract:  Gives  the  personal  views  of  the  author 
about  managing  large  software  developments.  He 
has  had  various  assignments  during  the  past  nine 
years,  mostly  concerned  with  the  development  of 
software  packages  for  spacecraft  mission  planning, 
commanding  and  post-flight  analysis.  In  these  as¬ 
signments  he  has  experienced  different  degrees  of 
success  with  respect  to  arriving  at  an  operational 
state,  on-time,  and  within  costs.  He  has  become 
prejudiced  by  his  experiences  and  relates  some  of 
these  prejudices  in  the  presentation. 


Rzepka85 

Special  Issue  on  Requirements  Engineering  Environ¬ 
ments.  W.  Rzepka  and  Y.  Ohno,  eds.  Computer  18, 
4  (April  1985). 

The  papers  in  this  issue  cover  approaches  such  as 
SADT  and  SREM,  with  special  emphasis  on  real¬ 
time  applications. 

Scacchi87 

Scacchi,  W.  Models  of  Software  Evolution:  Life  Cy¬ 
cle  and  Process.  Curriculum  Module  SEI-CM-10- 
1.0,  Software  Engineering  Institute,  Carnegie  Mellon 
University,  Pittsburgh,  Pa.,  Oct.  1987. 

Capsule  Description:  This  module  presents  an  in¬ 
troduction  to  models  of  software  system,  evolution 
and  their  role  in  structuring  software  development 
It  includes  a  review  of  traditional  software  life¬ 
cycle  models  as  well  as  software  process  models 
that  have  been  recently  proposed.  It  identifies  three 
kinds  of  alternative  models  of  software  evolution 
that  focus  attention  to  either  the  products,  produc¬ 
tion  processes,  or  production  settings  as  the  motor 
source  of  influence.  It  examines  hose  different  soft¬ 
ware  engineering  tools  and  techniques  can  support 
life-cycle  or  process  approaches.  It  also  identifies 
techniques  for  evaluating  the  practical  utility  of  a 
given  model  of  software  evolution  for  development 
projects  in  different  kinds  of  organizational  settings. 

Sommerville89 

Sommerville,  I.  Software  Engineering.  3rd  Ed. 
Wokingham,  England:  Addison-Weslev.  1989. 

This  book  contains  an  easy-to-rcad  introduction  to 
software  engineering  principles  and  issues.  It  em¬ 
phasizes  the  early  life -cycle  stages,  including 
“software  specification.” 

Sutcliffe88 

Sutcliffe,  A.  Jackson  System  Development.  New 
York:  Prentice-Hall,  1988. 

From  the  introductory  chapter: 

[Jackson  System  Development  (JSD))  is  organized 
in  three  separate  stages  which  guide  the  analyst 
through  the  systems  development  process.  Each 
stage  has  a  set  of  activities  with  clear  start  and  end 
points  (this  helps  the  analyst  using  the  method)  and 
facilitates  project  control  as  deliverables  can  be 
defined  for  each  stage.  The  three  stages  can  be 
outlined  briefly  as  follows. 

(a)  Modelling  stage  A  description  is  made 
of  the  real  world  problem  and  the  impor¬ 
tant  actions  within  the  syslem  arc  identi¬ 
fied.  This  is  followed  by  analysis  of  the 
major  structures  within  the  system,  called 
entities  in  JSD.  .  . 

(b)  Network  stage.  The  system  is  developed 
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as  a  series  of  subsystems.  First  the  major 
structures  are  taken  from  the  modelling 
stage  and  input  and  outputs  are  added; 
this  is  followed  by  the  analysis  of  the 
output  subsystem  which  provides  infor¬ 
mation.  and  then  of  the  input  subsystem 
which  handles  the  user  interface  and  vali¬ 
dation.  .  .  . 

(c)  Implementation  stage.  In  this  stage  the 
logical  system  specification,  which  is 
viewed  as  a  network  of  concurrently 
communicating  processes,  is  transformed 
into  a  sequential  design  by  the  technique 
of  scheduling.  This  is  followed  by  fur¬ 
ther  detailed  design  and  coding.  .  .  . 

JSD  begins  by  analysing  the  major  system  struc¬ 
tures  which  are  important  to  create  a  model  of  the 
system  problem,  the  entities.  Then  these  structures 
are  connected  together  to  create  a  network  model 
of  the  system,  while  at  the  same  time  the  design  is 
elaborated  by  addition  of  other  processes  to  create 
output,  and  to  handle  input  messages  and  user  in¬ 
teraction.  The  essence  ...  is  to  create  a  system 
model  of  reality  first  and  then  to  add  the  function¬ 
ality. 

JSD  is  usually  not  considered  to  support  require¬ 
ments  definition,  but  Jackson’s  emphasis  on  model¬ 
ing  the  problem  domain  makes  it  a  viable  alter¬ 
native,  for  information  systems,  to  functional,  top- 
down  approaches  such  as  Structured  Analysis.  This 
book  is  unique  in  showing  how  JSD  relates  to  more 
widely  used  software  requirements  and  design  tech¬ 
niques.  [Ward89]  also  shows  how  its  notation  re¬ 
lates  to  more  widely  used  requirements  notations. 

Teichrow77 

Tcichrow,  D.  “PSL/PSA:  A  Computer  Aided  Tech¬ 
nique  for  Structured  Documentation  and  Analysis  of 
Information  Processing  Systems.”  IEEE  Trans.  Soft¬ 
ware  Eng.  SE-3,  1  (Jan.  1977),  41-48. 

Abstract:  PSL/PSA  is  a  computer-aided  structured 
documentation  and  analysis  technique  that  was  de¬ 
veloped  for,  and  is  being  used  for,  analysis  and  doc¬ 
umentation  of  requirements  and  preparation  of 
functional  specifications  for  information  processing 
systems.  The  present  status  of  requirements  defini¬ 
tion  is  outlined  as  the  basis  for  describing  the  prob¬ 
lem  which  PSL/PSA  is  intended  to  solve.  The  basic 
concepts  of  the  Problem  Statement  Language  are 
introduced  and  the  content  and  use  of  a  number  of 
standard  reports  that  can  be  produced  by  the  Prob¬ 
lem  Statement  Analyzer  are  briefly  described. 

The  experience  to  date  indicates  that  computer- 
aided  methods  can  be  used  to  aid  system  develop¬ 
ment  during  the  requirements  definition  stage  and 
that  the  main  factors  holding  back  such  use  are  not 
so  much  related  to  the  particular  characteristics 
and  capabilities  of  PSL/PSA  as  they  are  to  or¬ 
ganizational  considerations  involved  in  any  change 
in  methodology  and  procedure. 


Tomayko87 

Tomayko,  J.  E.  Software  Configuration  Manage¬ 
ment.  Curriculum  Module  SEI-CM-4-1.3,  Software 
Engineering  Institute,  Carnegie  Mellon  University, 
Pittsburgh,  Pa.,  July  1987. 

Capsule  Description:  Software  configuration  man¬ 
agement  encompasses  the  disciplines  and  tech¬ 
niques  of  initiating,  evaluating,  and  controlling 
change  to  software  products  during  and  after  the 
development  process.  It  emphasizes  the  importance 
of  configuration  control  in  managing  software  pro¬ 
duction. 

Ward85 

Ward,  P.  T.,  and  S.  J.  Mellor.  Structured  Develop¬ 
ment  for  Real-Time  Systems.  New  York:  Yourdon 
Press,  1985-1986.  The  three  volumes  in  this  series 
are  Introduction  and  Tools ,  Essential  Modeling 
Techniques,  and  Implementation  Modeling  Tech¬ 
niques. 

This  book  is  an  alternative  to  [Hatley8 7]  for  teaching 
Real-Time  Structured  Analysis. 

Ward89 

Ward,  P.  T.  “Embedded  Behavior  Pattern  Lan¬ 
guages:  A  Contribution  to  a  Taxonomy  of  CASE 
Languages.”  J.  Syst.  and  Software  9,  2  (Feb.  1989), 
109-128. 

Abstract:  With  the  increasing  availability  of  CASE 
tools,  graphics-based  software  modeling  languages 
have  the  potential  to  play  a  much  more  central  role 
in  the  development  process.  Although  some  com¬ 
parisons  among  these  languages  have  been  made, 
no  systematic  classification  based  on  the  underlying 
abstractions  has  been  attempted.  As  a  contribution 
to  such  a  classification,  a  class  of  languages  desig¬ 
nated  Embedded  Behavior  Pattern  (EBP)  languages 
is  described  and  its  members  are  compared  and 
contrasted.  The  EBP  languages  include  the 
Ward/Mellor  and  Boeing/Hatley  Structured  Analy¬ 
sis  extensions,  the  Jackson  System  Development 
notation,  and  Harel's  StateChart-Activity  Chart 
notation.  These  notations  are  relevant  to  the  build¬ 
ing  of  specification  models  because  they  display 
clear  one-to-one  correspondences  between  elements 
of  the  model  and  elements  of  the  application 
domain.  These  notations  are  also  amenable  to  a 
style  of  model  partitioning  that  is  related  to  object- 
oriented  development. 

This  paper  is  a  detailed  comparison  of  the  notations 
described  in  [Harel88a),  [Hatley87],  and  [Ward85). 

Webster87 

Webster’s  Ninth  New  Collegiate  Dictionary. 
Springfield,  Mass.:  Merriam- Webster,  1987. 


36 


SEI-CM-1 1-2.1 


Software  Specifications:  A  Framework 


Yourdon89 

Yourdon,  E.  Modern  Structured  Analysis.  Engle¬ 
wood  Cliffs,  N.J.:  Yourdon  Press,  1989. 

Probably  the  most  comprehensive  and  up-to-date 
book  on  the  popular  Structured  Analysis  method. 
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